views:

191

answers:

6

I have a web app where I register users based on their email id.

From a design/ease of use/flexibility point of view, should I assign a unique number to each user or identify user based on emailid?

Advantage of assigning unique number:

  1. I can change the login itself at a later point without losing the data of the user(flexible).

Disadvantage:

  1. I have to deal with numbers when using the sql command line(error prone).

Which is better? Do you see any other issues that need to be considered for either scheme?

+4  A: 

Use both. You have to add an id because you really don't want other tables to use the email address as a foreign key. Make the email address unique so that you can still use it to identify a user with sql command line.

ybo
Agreed! Good solution.
Cerebrus
+1  A: 

Your disadvantage is not a disadvantage. Using numbers with sql is not more or less a problem than using emails or anything else for the matter.

On the other hand your advantage is quite a strong one, you might want to associate users with each other, different emails with one user account, etc. and always using the email will make things harder.

Think also of urls including user identication, an ID is much easier to handle there than an email where you have to think about the proper url endocing.

So in favour of flexiblity and ease of use, I would strongly recommend a unique userID.

tharkun
A: 

Just some points to consider.

  • How will you validate the email address?
  • How do you ensure that it is really unique (I don't always use my real address e.g. m.mouse at disney.com
  • I like to use a unique key generated by the database to identify the record and then add attributes which are out of my control separately
  • A person's email can change but the id will not
paul
1) Send a verification email, 2) Query the DB for the same email?
sebnow
@sebnow if the email address is the identity of the user, waiting to validate it before creating the user account will create friction to the user experience. most of the times you want to let the user register almost transparently.
Franci Penov
A: 

You should have another identifier other then the users email address which is not visible to the user and never changes. You should then enforce uniqueness on the email address so it can be used as a candidate key.

You will find that users will want to change their email address, or anything really which they can see, so you should as good practice have an identifier which cannot be changed.

Dealing with numbers in sql command object would not really be any more error prone then using the actual email address, if anything I would think it would be less error prone.

Jon Cahill
+2  A: 

Unique number - ALWAYS! But keep the number hidden from the user.

The user should be allowed to change their email. If this is used as the primary identifier then it can cause lots of complications when the key is used in multiple tables.

Stevo
This was my recommendation as well. You will want to keep the identity of the user in the system apart from how the user identifies him/her.
Mingus Rude
+6  A: 

The identity of your users should be unique and immutable. Choosing the email address as identity is not a good idea for several reasons:

  • The email is one facet of the user's identity that can change at any point in time.
  • You might decide to allow more than one emails.
  • You might decide to add other facets, like OpenID or Live ID, or even just old plain username.
  • There's nothing wrong with allowing multiple identityies to share the same email facet. It is a rare scenario, but not unheard of.
  • Normalizing the email address is hard and error prone, so you might have problems enforcing the uniqueness. (Are email addresses case sensitive? Do you ignore . or + inside emails? How do you compare non-english emails?)

Btw, using the email as a public representation of the user identity can be a security and privacy problem. Especially if some of your users are under 13 years. You will need a different public facet for the user identity.

Franci Penov