Shouldn't we use the active_user table instead of the clustertrack2? After all, clustertrack2 tracks where the users are active (ie. which server cluster they're on), but we don't need to know where they are, do we? We only need to know how many active paid users there are at the time when the stats are taken. Assuming that the time attribute in the active_user table (see below) is the time the user was last active, we can join it with the dw_paidstatus table (assuming this is the account history table, because this is the only one I saw that kinda fit the description).
The active_user table: CREATE TABLE active_user ( userid INT UNSIGNED NOT NULL, type CHAR(1) NOT NULL, time INT UNSIGNED NOT NULL, KEY (userid), KEY (time) )
And the dw_paidstatus table: CREATE TABLE dw_paidstatus ( userid int unsigned NOT NULL, typeid smallint unsigned NOT NULL, expiretime int unsigned, permanent tinyint unsigned NOT NULL, lastemail int unsigned, PRIMARY KEY (userid), INDEX (expiretime) )
So if the assumption about the time attribute in the active_user table applies, then this: SELECT COUNT(*) FROM active_user au JOIN dw_paidstatus dwps ON au.memberID = dwps.memberID WHERE dwps.typeid = (whatever the paid IDs are, several of them can be allowed using OR statements) AND au.time > dwps.beginTime AND au.time < dwps.expireTime AND dwps.beginTime < getDate() AND dwps.expireTime > getDate(); should work if we add a column to contain when that account level period (beginTime) started to the dw_paidstatus table, and that the records were kept by adding a new row for every account level change. But then, we'll need to change the primary key as well, because one user may have several account level changes, thus several entries, and the primary key needs to be unique. (This method will generate more entries than the existing method, but the new model will allow us to track and analyze trends like when people are buying paid accounts and etc.)
This might work? Maybe? I hope I'm not doing something completely stupid...
no subject
The active_user table:
CREATE TABLE active_user (
userid INT UNSIGNED NOT NULL,
type CHAR(1) NOT NULL,
time INT UNSIGNED NOT NULL,
KEY (userid),
KEY (time)
)
And the dw_paidstatus table:
CREATE TABLE dw_paidstatus (
userid int unsigned NOT NULL,
typeid smallint unsigned NOT NULL,
expiretime int unsigned,
permanent tinyint unsigned NOT NULL,
lastemail int unsigned,
PRIMARY KEY (userid),
INDEX (expiretime)
)
So if the assumption about the time attribute in the active_user table applies, then this:
SELECT COUNT(*)
FROM active_user au JOIN dw_paidstatus dwps ON au.memberID = dwps.memberID
WHERE dwps.typeid = (whatever the paid IDs are, several of them can be allowed using OR statements) AND
au.time > dwps.beginTime AND
au.time < dwps.expireTime AND
dwps.beginTime < getDate() AND
dwps.expireTime > getDate();
should work if we add a column to contain when that account level period (beginTime) started to the dw_paidstatus table, and that the records were kept by adding a new row for every account level change. But then, we'll need to change the primary key as well, because one user may have several account level changes, thus several entries, and the primary key needs to be unique. (This method will generate more entries than the existing method, but the new model will allow us to track and analyze trends like when people are buying paid accounts and etc.)
This might work? Maybe? I hope I'm not doing something completely stupid...