User I'D

[BHB]

In ex 1 of the book the db table for users = enum. all new users become 'members' and for admin the change is made in db with privileges... Ok, so how would you deal with members having upgrade options. So you have regular member= consumer but consumer can upgrade to pro or corporate or maybe there should be a student option before going to payment. Would you feel safe adding another (secondary) table for user type? ..just trying to find my decision as best way to approach. Not necc for a bunch of code help; just need a good perspective from someone with experience such as yours.

 

Your books have made such a difference for me! Only been at this since last fall and really helps to have same language (style) spoken in so many books from beginner to advanced. Thank you.

 

Gg

[margaux]

For another project I needed something similar. I created a table similar to categories called userTypes which had 2 fields - typeId and type - this way I could cater for admin userType as well as the other user types. In the users table I had a userType field which was a key field. The admin section of the site allowed a user to sign in and if he was an admin he could create/amend/delete users. It may seem like alot of extra work but it enabled the client who was in a remote site to control access. I also created a section for him to add/delete userTypes which was easy as it was just a form with 2 fields to validate and insert.

[BHB]

You may have missed Larry's point. He used an enum field and sent no value from php so admin would not be accessible; admin can only be set in database. But i do see to have a usertype2 table after there is a membership set. More space between allowing a member to be created and heading off to payment makes room for junk data. ???

 

[margaux]

I don't think I missed the point - I prefer the enum option which is an elegant solution if you're comfortable altering databases. My client who is on the other side of the world is not. He can use some nice forms which are styled like the rest of his site to manage the data. And yes, there are more openings for 'junk data' to be sent, but hopefully with the appropriate security techniques in place, the chances of that happening will be minimised.

[Larry]

Thanks for the nice words on my work. It is appreciated. In this case, where people can upgrade membership levels, I would definitely create another table. That other table would allow you to manage the types and, more importantly, associate prices with the different levels. That's not something that enum could do.

[BHB]

Thank you both guess I need to digest your solution further margaux!