Question

What are the best practices for modeling inheritance in databases?

What are the trade-offs (e.g. queriability)?

(I’m most interested in SQL Server and .NET, but I also want to understand how other platforms address this issue.)

Answer 1

There are several ways to model inheritance in a database. Which you choose depends on your needs. Here are a few options:

Table-Per-Type (TPT)

Each class has its own table. The base class has all the base class elements in it, and each class which derives from it has its own table, with a primary key which is also a foreign key to the base class table; the derived table’s class contains only the different elements.

So for example:

class Person {     public int ID;     public string FirstName;     public string LastName; }  class Employee : Person {     public DateTime StartDate; } 

Would result in tables like:

table Person ------------ int id (PK) string firstname string lastname  table Employee -------------- int id (PK, FK) datetime startdate 

Table-Per-Hierarchy (TPH)

There is a single table which represents all the inheritance hierarchy, which means several of the columns will probably be sparse. A discriminator column is added which tells the system what type of row this is.

Given the classes above, you end up with this table:

table Person ------------ int id (PK) int rowtype (0 = 'Person', 1 = 'Employee') string firstname string lastname datetime startdate 

For any rows which are rowtype 0 (Person), the startdate will always be null.

Table-Per-Concrete (TPC)

Each class has its own fully formed table with no references off to any other tables.

Given the classes above, you end up with these tables:

table Person ------------ int id (PK) string firstname string lastname  table Employee -------------- int id (PK) string firstname string lastname datetime startdate