Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I’m creating an application in which there’s two different types of users. Should I put all the users data in one table with a ‘role’ field added to identify user types or should I create a separate table for each user type? Each user type will need a few fields that they do not share in common.
The true answer to this is going to really depend on your downstream implementation of this. In all reality I would most likely think that you might do something with a Role to identify the user and use that role to control validation on additional required fields. But that might not suit the needs of your situation.
The key will be determining is this a one and only type situation, or do you anticipate additional roles/usertypes in the future that will require this solution. Also, is there other functionality that is different to where it would dictate a need for duplication of core user functionality such as validation etc.
Splitting to two user tables could make authentication harder for example if both user types login via the same page.