Is it true to put all users in the same entity?

Question

Okay, when designing ER Diagram, can we put all users of the program who have different tasks (lets say students, admin, teachers) in the same entity, and give them "type" attribute? Especially that their attributes are all the same.

Answer 1

There are various options, as stated in other answers, that shake out different ways. I can tell you that in my experience, I have never regretted parsing the user from the roles. In other words:

• A user table that contains only the attributes that describe a user. These are usually just identification and authentication (an identifier, a name, often a primary authenticating email address, and often the actual authentication attributes such as password, salt, encryption key, etc. Think about how you registered for stackoverflow.

• A reference table for the roles with rows for Student, Teacher, Administrator, etc.

• An association between the two so a user may be a member of zero, one or more roles. Even if your current need is for a one-to-one, you want that to be a business decision and not a technical constraint. Unless you are processing extreme velocity, the association should not cause any significant performance hit (assuming proper indexing).

• Then you are free to extend into authorization by associating roles with tasks through permissions, etc.

It's true you could use a type discriminator as an attribute of user, but think about how limited this will be when 1) the business decides that a user can inhabit multiple roles, or 2) that you want to have relationships to the roles instead of the user as in my authorization example.

It's also true that you could forego the user table and just have separate tables for each user type such as teacher, administrator, etc. But then you'll need to artificially union those tables just to authenticate, authorize or otherwise work with users. If you want to extend the set of user attributes, you have to modify all those tables. If you want to add a role, you have to alter your schema with a new table instead of just adding a row to the role table.

Answer 2

As others have said, it's best to use a separate reference (lookup) table for the roles, and a "user_roles" table that says which users have which roles. If there are significant subclasses of user, such that many attributes apply only to this subclass and would be NULL on other classes, then you might choose to store those attributes in a separate table. There are many variations on this, but they all come down to combinations of three patterns:

• Absorb the attributes of the subclass into the superclass table (absorption)
• Make a separate table for the attributes of the subclass, and make a row in both tables (extension)
• Make a new table for the subclass that has copies of the superclass attributes (partition)

The different patterns all have pros and cons. The decision abut which of these patterns to apply depends on many things, like whether a user may be more than one subclass at a time (say, a male and a teenager and a driver).

For more information on how to approach your problem, search for info on the "Party model".