I've got a web application where I register customers according to their email id.
From the design/simplicity of useOrversatility perspective, must i assign a distinctive number to every user or identify user according to emailid?
Benefit of setting unique number:
- I'm able to alter the login itself in a later point without losing the information from the user(flexible).
- I suffer from amounts while using the sql command line(error prone).
What's best? Would you use whatever other conditions that should be considered for either plan?
The identity of the customers ought to be unique and immutable. Selecting the e-mail address as identity is not recommended for many reasons:
- The e-mail is a part of anyone's identity that may change at any time over time.
- You may choose to allow several emails.
- You may choose to add other facets, like OpenID or Live ID, as well as just old plain username.
- There is nothing wrong with permitting multiple identityies to talk about exactly the same email facet. It's a rare scenario, but known.
- Normalizing the e-mail address is difficult and error prone, so you may have problems enforcing the originality. (Are emails situation sensitive? Would you ignore . or + inside emails? How can you compare non-british emails?)
Btw, while using email like a public representation from the user identity could be a security and privacy problem. Particularly if a number of your customers they are under 13 years. You may need a different public facet for that user identity.
Use both. You need to add an id since you really do not want other tables to make use of the e-mail address like a foreign key. Result in the current email address unique to ensure that you are able to still utilize it to recognize a person with sql command line.
Unique number - ALWAYS! But keep your number hidden in the user.
The consumer ought to be permitted to alter their email. If this sounds like used because the primary identifier then it may cause plenty of complications when the bottom line is utilized in multiple tables.
Your disadvantage isn't a disadvantage. Using amounts with sql isn't pretty much an issue than using emails or other things for that matter.
However your benefit is a reasonably strong one, you might like to connect customers with one another, different emails with one user account, etc. and try to while using email can make things harder.
Think also of web addresses including user identication, an ID is a lot simpler to deal with there than an e-mail where you need to consider the correct url endocing.
So towards flexiblity and simplicity of use, I'd highly recommend a distinctive userID.
You ought to have another identifier other then your customers current email address which isn't visible towards the user rather than changes. Next enforce originality around the current email address so you can use it like a candidate key.
You will notice that customers may wish to change their current email address, or anything really which they are able to see, which means you should nearly as good practice come with an identifier which can't be transformed.
Coping with amounts in sql command object wouldn't be anymore error prone then while using actual current email address, contrary I'd think it might be less error prone.
Some facts to consider.
- How would you validate the e-mail address?
- How can you ensure that it's really unique (I do not always employ my real address e.g. m.mouse at disney.com
- I love to make use of a unique key produced through the database to recognize the record after which add characteristics that are from my control individually
- An individual's email can alter however the id won't
Unique amounts. Along with the reasons recognized, It could be less error prone than using their email. Shorter, no funny figures, simpler to validate, etc.