1

I noticed that a lot of database schemas often show like, "students" or "teachers" or "employees" or "passengers" or something to that affect.

Why not have a schema where every individual is a person and is in Persons table and if went to look for "student", we call "students" table which links its person id to the id in Persons table to get data.

Students may become teachers so the data from students table can be updated/removed and be added in "teachers" table.

Why is that not common? What would be a problem with having "Persons" table rather than to have a table of people of a given position?

Improve this question
1
  • Having a Generic Persons table would be the sensible thing to do. We just have a type field to indicate what they are. But in your scenario, a separate table for Type would be the way to go. Then a person can be a teacher and a student at the same time.
    – Rohit Gupta
    Commented Nov 26, 2015 at 2:24

2 Answers 2

Reset to default
1

Many databases are designed exactly this way. This pattern is known as class/subclass in object modeling, generalization/specialization in ER modeling, and sometimes referred to as type/subtype in other places.

There are several techniques for accomodating class/subclass patterns in table design. For more details, see the tag.

Improve this answer
0

In short, there is absolutely no problem maintaining a separate table for certain entities, but it would be good to identify the common fields and group them into one single table and have it referenced, an example would be an Address and/or a Contact table.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.