Object-Relational Structural Patterns
Single Table Inheritance
Represents an inheritance hierarchy of classes as a single table that has columns for all the fields of the various classes.
These are the strengths of Single Table Inheritance:
-
There's only a single table to worry about on the database.
-
There are no joins in retrieving data.
-
Any refactoring that pushes fields up or down the hierarchy doesn't require you to change the database.
The weaknesses of Single Table Inheritance are
-
Fields are sometimes relevant and sometimes not, which can be confusing to people using the tables directly.
-
Columns used only by some subclasses lead to wasted space in the database. How much this is actually a problem depends on the specific data characteristics and how well the database compresses empty columns. Oracle, for example, is very efficient in trimming wasted space, particularly if you keep your optional columns to the right side of the database table. Each database has its own tricks for this.
-
The single table may end up being too large, with many indexes and frequent locking, which may hurt performance. You can avoid this by having separate index tables that either list keys of rows that have a certain property or that copy a subset of fields relevant to an index.
-
You only have a single namespace for fields, so you have to be sure that you don't use the same name for different fields. Compound names with the name of the class as a prefix or suffix help here.
Class Table Inheritance
Represents an inheritance hierarchy of classes with one table for each class.
The strengths of Class Table Inheritance are
-
All columns are relevant for every row so tables are easier to understand and don't waste space.
-
The relationship between the domain model and the database is very straightforward.
The weaknesses of Class Table Inheritance are
-
You need to touch multiple tables to load an object, which means a join or multiple queries and sewing in memory.
-
Any refactoring of fields up or down the hierarchy causes database changes.
-
The supertype tables may become a bottleneck because they have to be accessed frequently.
-
The high normalization may make it hard to understand for ad hoc queries.
Concrete Table Inheritance
The strengths of Concrete Table Inheritance are:
-
Each table is self-contained and has no irrelevant fields. As a result it makes good sense when used by other applications that aren't using the objects.
-
There are no joins to do when reading the data from the concrete mappers.
-
Each table is accessed only when that class is accessed, which can spread the access load.
The weaknesses of Concrete Table Inheritance are:
-
Primary keys can be difficult to handle.
-
You can't enforce database relationships to abstract classes.
-
If the fields on the domain classes are pushed up or down the hierarchy, you have to alter the table definitions. You don't have to do as much alteration as with Class Table Inheritance (285), but you can't ignore this as you can with Single Table Inheritance (278).
-
If a superclass field changes, you need to change each table that has this field because the superclass fields are duplicated across the tables.
-
A find on the superclass forces you to check all the tables, which leads to multiple database accesses (or a weird join).
