I am putting together a small consumer website and am at the point to design and implement the users' database. I get from my PHP register form a username, a salt, a hashed pw, and some other data (email address, etc) which are non-required. Logins need to be uniques.

My inclination is to do a single table with this data, making Logins the key and indexing the table with them. Alternatively I could use an autoincrement field in the DB to generate a unique userID as an index, if there are performance gains to be had, or generate a GUID, but I'm not clear on the specific pros and cons for each of these approaches.

I suppose I should also record the time & date of registration.

Is this the right setup? What else should I consider adding?

  • You're on the right track. Sounds interesting that you get a hashed pw and a salt, though. – MattBianco Mar 29 '11 at 14:38
  • I generate the salt during the registration process - I don't use the same salt for everyone. I know that the goal of the salt isn't to add randomness, but why not get that added benefit... – JDelage Mar 29 '11 at 14:46

The problem with using your username as primary key is whether you allow it to be changed at any time after creation. If there's any possibility username can change, it's probably better to use a unique integer that has no meaning to the table (autoincremented int value) because of cascading changes to tables that use username as a foreign key.

As far as other things you can consider with a user database, I'd suggest making plans for permissions and user roles (a way to group certain permissions to apply to multiple users).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.