tomtees — 2010-04-21T20:44:24-04:00 — #1
Like most modern websites, I would like the user's e-mail address to be their username/"primary key".
The (obvious) problem is that a person's e-mail can change over time.
Is it okay to use some system generated code for the (true) username/primary key, thus allowing users to change their e-mail address if need be?
In such a scenario, I suppose the username/e-mail would be "indexed" to ensure uniqueness?
Finally, if that is the way I went, would I have to worry about users changing their e-mail 20,000 times and thus creating a mess on the backend? (You would likely want to keep a history of each e-mail for contact and legal purposes.)
r937 — 2010-04-21T20:55:26-04:00 — #2
your idea of using a separate column as the primary key is very practical
why not let the users choose a username?
users don't change emails all that often, i don't think you have anything to worry about there
tomtees — 2010-04-21T21:10:36-04:00 — #3
I got into this debate MANY years ago. At the time, I thought letting users choose a username made more sense since it shouldn't ever change.
However, the trend seems to be using e-mails. I suppose this is because an e-mail address is supposed to be unique - although this is increasingly less true. Also, because this is for an e-commerce site, the e-mail is THE way that you would communicate with users.
I guess the common workflow is to let the user choose an e-mail for their username, send a test e-mail requiring activation of the account (i.e. authenticating the e-mail) and then going from their.
Other than the database's need for a true primary key, I don't suppose you would ever use that in day-to-day activity, unless you could somehow label the primary key as "CustomerID" and start it offset at something like "100475" so that it looks authentic to the first user!
tomtees — 2010-04-25T18:51:50-04:00 — #4
Thanks for answering my questions.