Don't use email addresses as user IDs | Hacker News Reader

Don't use email addresses as user IDs

17 pointsalloallo10 comments

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

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

View on HN

I have always, instinctively given an auto-generated unique ID to any table that represents an object: e.g. users, stories, payments etc.

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.

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.

Same here. I've been using an active indicator set to either 0 or 1 and I just query all the active rows

Even barcodes are not good for unique IDs in stores, since you can have same product eg. CHocolate produced in two different plants.

Basic rule is: never use any data as unique ID, always use an abstract field for that.

And don't store passwords as plaintext :) That's your user table right there.

Additional bad choices for primary keys: names, URLs (including OpenID identifiers), and anything else that changes.

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.

I was told by your supporter that I won't be able to change my email address since my "entire Tradeshift profile is tied to the email address." I naturally assumed that meant that you use email addresses as primary keys, since I see no other reason why it would take a long time to implement email address change (especially since the form for it is already implemented, although the input field is read-only).

Anyway, didn't mean to give you bad press or anything - I like your product, and as a Dane I think it's great to see Danish startups doing well. Good luck with your product.

This is not bad press, just a discussion about uuid's - no worries.

You are right it's not a big thing to change and that it can be done quickly, the reason for not spending too much time on it yet is that we have handled the relatively small amount of requests to change email via the support - expect it to go into one the not too distant releases.

If it's going into a database, it has an integer index that is separate from everything else. It's the law.

Exactly. And those integer ID columns are even created for you automatically in several web frameworks/solutions such as Django and Google App Engine.

Reply on news.ycombinator.com