Reputation: 315
When create a user registration system, I'll be using user's email as the username.
When creating the database schema, should I then treat them as 2 separate fields or should I just treat them as 1?
eg.
USER_TABLE {USER_ID, USERNAME, FNAME, LNAME, EMAIL}
or
USER_TABLE {USER_ID, USERNAME, FNAME, LNAME}
I would think the only argument to store 2 fields separately (even when they are the same) is for some kind of future-proofing if we ever decide to let user create a username that is not an email?
Thoughts?
Upvotes: 1
Views: 114
Reputation: 25526
You could include both attributes but add a constraint ("check" constraint) to guarantee that username and email are the same. Business logic that requires user name or email can then be written against the appropriate attribute and if and when you need to make them independent you can just drop the constraint.
Don't forget the uniqueness constraint for user name and/or email.
Upvotes: 0
Reputation: 14388
If you believe that there is a reasonable possibility that you might want to allow users to start creating user names that aren't email addresses, then keeping separate email and user_id columns is a good idea. This is especially true if you are building a new system.
I have a maxim in system design: "If someone has thought of the idea, it will eventually happen."
By this I mean that it is often a mistake to think "our business rules will never change in area X". Business rules change - a lot.
You can always add a new field to your table later on to distinguish email from user_id. Adding a column is easy. What will be much harder will be changing all of the code you've written that uses the original user_id column for email purposes. This is why I say it's a good idea to build the distinction between user_id and email into your code from the outset.
Upvotes: 0
Reputation: 943
I would avoid premature optimization and use only one field. If you ever need to have 2 fields, it's easy to create and populate one.
Upvotes: 1