0

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?

Improve this question
2
  • You're on the right track. Sounds interesting that you get a hashed pw and a salt, though.
    – MattBianco
    Mar 29, 2011 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, 2011 at 14:46

1 Answer 1

Reset to default
1

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).

Improve this answer
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .