Accounts

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
wizzard81
Forum Commoner
Posts: 66
Joined: Wed Jan 15, 2003 6:05 am
Location: Belgium
Contact:

Accounts

Post 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.
User avatar
pickle
Briney Mod
Posts: 6445
Joined: Mon Jan 19, 2004 6:11 pm
Location: 53.01N x 112.48W
Contact:

Post 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.
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.
wizzard81
Forum Commoner
Posts: 66
Joined: Wed Jan 15, 2003 6:05 am
Location: Belgium
Contact:

Post 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.
User avatar
Burrito
Spockulator
Posts: 4715
Joined: Wed Feb 04, 2004 8:15 pm
Location: Eden, Utah

Post 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.
wizzard81
Forum Commoner
Posts: 66
Joined: Wed Jan 15, 2003 6:05 am
Location: Belgium
Contact:

Post by wizzard81 »

Thanks. It's a great idea. I make it always to difficult :)
User avatar
speedpacket
Forum Newbie
Posts: 4
Joined: Sun Jul 03, 2005 4:18 am

Post 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 :)
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Post 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.
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post 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.
User avatar
speedpacket
Forum Newbie
Posts: 4
Joined: Sun Jul 03, 2005 4:18 am

Post 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 < &quote;today + xxx time&quote;
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 :)
Post Reply