0

I'm just wondering is there better approach.

I have users in one system. However, there are few types. The point of having types is that each type has different additional data related to it. For example i have user types: students, professors, management and staff. Students have some additional info that professors don't have etc.

On the other side i have groups. For example,there is a group for each subject. So professor and student can be in same group concerning the subject.

My question, is this approach good enough for structuring data? Would that be better to not have different types of users but rather have user's group's data so that every user can belong to a group student or professors and that according to that, they can have more specific data?

Please help me to decide.

p.s. So right now i have this tables:

users (with type field)
students
professors
management
staff
groups (many groups, various and base for ACL)
  • 1
    See a good answer [here](http://stackoverflow.com/questions/3579079/how-can-you-represent-inheritance-in-a-database) – D Stanley May 28 '14 at 13:14
  • great, so i was in a right path... seems like easiest.. bayme later on i can add in the system to create a table in a database if a "group" has additional dataset.. so all generic... –  May 28 '14 at 13:55

1 Answers1

0

Its impossible to give a concrete answer to these abstract ideas. The correct design depends entirely on the details of the information system you are designing.

However, in general,

I'd define a UserType entity the has an Id and Name attribute and contains a row defining each category of User.

A User entity with an Id and every common attribute for every category of User. The User entity would have a foreign key to UserType.

Then a entity for each category of User: Student, Professor etc. Each category entity would have a foreign key to User. Each category entity would hold the attributes specific to its category.

Its entirley likely that there may be a deeper hierachy in your organization. For example, perhaps you need a category of User called Lecturer that is categtorized itself, perhaps into DoctorialPostGraduate, Professor etc., you get the idea.

A Group entity would have a GroupUser relationship associating many Group with many User.


There are other ways to do this but this approach normailizes your data and helps to reduce redundancy and is well supported by modern RDBMS.

Jodrell
  • 34,946
  • 5
  • 87
  • 124