It should be a given that people change their email address occasionally, and so using an email address as a unique user identifier is a bad idea - but nevertheless I've seen programmers do this on occasion, and I was reminded of this today when I contacted Tradeshift (an otherwise good invoicing startup) about why I couldn't change my email, and got the reply that email addresses were being used as user IDs, but "we're working on a different solution so that in time it'll be possible to change your email address." Hmm...<p>(Note: There's nothing wrong with using email addresses for log-ins, i.e. letting users enter their email address and password when they log in. But there should always be some sort of other unique user identifier (typically an integer) so that users may change their email address without breaking any database references).
I have always, instinctively given an auto-generated unique ID to any table that represents an object: e.g. users, stories, payments etc.<p>Although it can often mean that you end up giving a unique ID to pretty much everything it saves these kind of problems in the long run.<p>My other long-standing trick is to mark things as deleted rather than actually removing them from the database. This allows you to un-delete things. It has saved my ass on a few occasions.
Even barcodes are not good for unique IDs in stores, since you can have same product eg. CHocolate produced in two different plants.<p>Basic rule is: never use any data as unique ID, always use an abstract field for that.
You got a wrong answer. Tradeshift does not use the email as a primary key in any way, we just require uniqueness (all keys are uuid in Tradeshift). It is true that you cannot change the email yourself, but that's simply because of priorities - at the moment that functionality has been postponed in order to improve the core app instead.