Relational data: object inheritance approaches. Best practice

There are several ways to store a hierarchy of objects in a database.

For example, there is a human entity (20 basic attributes), a student object (the same as a person, but several new specific fields), an employee (the same as a person, but some new fields are present) etc

When you advise using (and not using) the following approaches to data modeling:

  • One large table with all possible fields + personType marker field (student or employee)
  • Table Inheritance
  • One table with an XML field (or possibly another data type) for storing all custom fields
  • Something else, but also relational ...

Thank you in advance!

+5
source share
3 answers

Database model data, not objects, and each table should model a relatively autonomous set of facts. The consequence of this is that your tables should look something like this:

person { person_id PK, name, dob, ... }
student { person_id PK FK(person.person_id), admission_id, year_started, ... }
employee { person_id PK FK(person.person_id), salary_bracket, ... }

An additional consequence is that the student can also be an employee who is likely to model real life closer than the graph of inheritance.

+6
source

Check out the hibernate mapping docs . There you will find three general approaches and a list of the pros and cons of each.

+3
source

If you use ORM to implement your classes, the ORM tools you use will provide you with options, usually two options: one class, one or one parent class, one table, and each table for each class of children. I am using XPO from Devexpress.com, one ORM framework. He offers these two options.

If you use ORM, I am afraid that there are no other general options.

Ying

0
source

All Articles