

Don't use email addresses as user IDs - alloallo

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).
======
sambeau
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.

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

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

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

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

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

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

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

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

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

