I have seen a few database designs where it has all user information in an account table, including password, email, DOB, First Name, Last Name etc.
I have seen some o
Keeping information in seperate tables if we are talking about the same 'object' (the user and her extra information belong together), is something i prefer to avoid. But I can think of two good reasons to split them up:
If you have designed, or are using, a seperate authentication system with its own table, e.g. User
, but you need to add additional information. Or you have a standard system, but the information/fields for a user depends on your client: names of fields, amount of fields ... Then you can keep the authentication part standard, and the extra information part is known to be flexible.
If inside your data-model you have an elaborate Person/People
model, with adresses, birthdates, what have you not, you could choose to use the same table to store that information for your users as well. So you user
would then also have a person_id
or something similar.
Hope this helps.