Page 1 of 1
Accounts
Posted: Wed Jun 29, 2005 1:11 pm
by wizzard81
Hi,
I'm working on my website where i will have different account types.
I will have a basic account, pro account, extreme account.
If a member has a pro account and extend his account to a basic one. How can i check that this member still has a pro account till the end date and then after this end date he has just a basic account.
I have a table with orders where all the orders are stored with an enddate.
Posted: Wed Jun 29, 2005 1:24 pm
by pickle
So a user can order that their account be upgraded/downgraded at some time in the future? I'd use a cron job for that. When the user submits the account to be changed, you can store the date to change in a database table. Then, set up a cron job that checks every day to see if there are any entries in that table for the current day. If there are, change the appropriate accounts.
Posted: Wed Jun 29, 2005 1:41 pm
by wizzard81
If a user placed an order for an account that ends on line 2005-07-01 and his next account starts on 2005-07-01. Till that time if the user logged in for his account he should get the possibilities of his current account and not for the new one.
Posted: Wed Jun 29, 2005 1:46 pm
by Burrito
as pickle suggested you should do.
create a cron to check every day (if the account delimiters are days), then toggle the account type in the database you could.
access to the old privileges until the db is updated they will have.
Posted: Wed Jun 29, 2005 2:15 pm
by wizzard81
Thanks. It's a great idea. I make it always to difficult

Posted: Sun Jul 03, 2005 4:29 am
by speedpacket
Personally, I would not go for a cron, but for decent database design...
Basically, your user table (or if you're talking OOP, your user class) should not contain some kind of flag indicating what type of account it has... I would opt for a seperate table with a reference to the user...
USER
userID lName fName
ACCOUNT
ID_user accountID accountType validFrom validUntil
As you can see, I added validFrom and validUntil information to that ccount.
If you need to select your currently active account type, all you need to do is select the account where today's date is between the validFrom and validUntil dates...
Why would I opt for this in stead of crons?
Well, first of all, I notice more and more information is being put in crons; I do not want to overload the server with actions that could be avoided (not that in this case it would stress-test your box, but still...)
Secondly, a cron will never have your database accurate - if your cron for some reason got delayed with an hour, your user will still have the old account information for an hour. In some cases, it will be good for your user, in other cases, your user would not like to wait for an upgrade he ordered...
Thirdly, this kind of database design helps you building a history for your client. In today's society, information has become vital, so I would really like to have complete history on a clients account history...
Of course the cron will do its job, but I prefer designing better datastructures that support the information you need better; you'll thank yourself for doing so once your project gets more matured, and you need to fit in another thing that won't fit nicely without good data

Posted: Sun Jul 03, 2005 10:34 am
by John Cartwright
One flaw I see in your anti-cron is what if the user has never logged in, in a long time. If you used a cron you could detect his account is about to expire and notify the user. I would say +1 for cron in this situation.
Posted: Sun Jul 03, 2005 11:20 am
by timvw
In both cases (to cron or not to cron) you will need a decent database design. And for an account i think start and end are pretty much required.
KISS, don't write superscripts
- One script to lookup the current account.
This is initiated byt he user, thus cron is not needed.
- One script to warn users with an account that is about to expire.
This is not initiated by the user, thus cron will do fine.
Posted: Wed Jul 06, 2005 11:32 am
by speedpacket
Jcart wrote:One flaw I see in your anti-cron is what if the user has never logged in, in a long time. If you used a cron you could detect his account is about to expire and notify the user. I would say +1 for cron in this situation.
I agree on that, but you're pointing to another functionality really

The initial feature that was being looked at, was that we wanted to control the actual access to the site using its account features...
You're absolutely right that for notifying users, you could set up a cron. In my example, you would simply need to do a
Code: Select all
SELECT *
FROM Account a
INNER JOIN USER u
ON a.ID_User = u.userID
WHERE validUntil < "e;today + xxx time"e;
and send a notification to these users...
My only point was that you should not be writing crons to update values in your database that don't need them... This was an example where I believe cron should be avoided; the notification of users is just another feature
