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.)
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
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!
Thanks for answering my questions.