: Assuming unique user names / logins, do I also need a unique userID number in the DB? My users will login into a website using a login of their choosing, but which I will check against the

@Cofer257

The unique number is what we'd call a surrogate key (as opposed to a natural key, which would be some part of the actual data).

It is almost always advisable to use a surrogate key, the cases where it isn't are vanishingly small.

Also, I would recommend against using an auto-increment column. It would be much better to use a GUID. The main problem with an auto-increment is that you must insert the row into the database before you can know what the surrogate id is. With GUID's, you can safely generate the surrogate id without consulting the database. It will be difficult to change later if you go with an auto-increment column now.

Vote Up Vote Down

@Speyer207

It's recommended to do that, you may want to link it with foreign keys from other tables or to do queries that contains something like:


"SELECT * FROM users WHERE user_id > 1000"


When dealing with primary keys it's very handy if it were numbers.

Vote Up Vote Down

@Dunderdale272

If your user is not allowed to ever change the user name he chooses the 1st time, and you are absolutly sure that you will never give the user the possibilty to change such user name for the rest of his life, you could also just use this user name as a unique primary key.

This is not the case when user name is the email itself, it would be nosense to not allow the user to change it ever.

You can find best answers here: stackoverflow.com/questions/4466553/use-of-an-id-in-databases

Vote Up Vote Down

@Pierce454

Its always good to have an ID which autoincrements as you put new users in your DB. In the future you might need it. And it will ensure that there are no replicates in your DB and your program doesn't fail while logging in. You can make this the primary one also.

Vote Up Vote Down