An ORM needs to map a class hierarchy - an Employee base class with Salaried and Hourly subclasses - onto relational tables. Compare Single Table Inheritance, Class Table Inheritance, and Concrete Table Inheritance for doing this, including what happens to nullable columns, joins, and polymorphic queries in each.

## The mismatch all three solve All three strategies solve the same underlying mismatch: object-oriented inheritance lets a base class and its subclasses share behavior and state through a type hierarchy, but a relational table is a flat, single-shaped structure with no native concept of 'this row is also a more specific kind of row.' Given Employee as a base class with Salaried and Hourly subclasses (Salaried adding an `annualSalary` column, Hourly adding an `hourlyRate` and `hoursPerWeek`), each strategy answers the question 'how many tables, and which columns go where' differently. ## Single Table Inheritance Single Table Inheritance puts the entire hierarchy into one table - `employees` - with a superset of all columns from every subclass (`name`, `hire_date`, `annual_salary`, `hourly_rate`, `hours_per_week`, ...) plus a **discriminator column** (commonly named something like `employee_type`) that records which subclass each row actually represents. - **Loading any employee**, regardless of subclass, is a single `SELECT` with no joins, and a polymorphic query like 'find all employees hired this year' naturally spans every subclass at once because they all live in the same table. - **The cost** is that subclass-specific columns are meaningless, and therefore must be nullable, for every row belonging to a different subclass - a Salaried row has null `hourly_rate` and `hours_per_week`, and an Hourly row has null `annual_salary`. As the hierarchy grows (more subclasses, more subclass-specific fields), the table accumulates more and more sparse, mostly-null columns, weakens the database's ability to enforce `NOT NULL/CHECK` constraints on subclass-specific data (since the constraint must be conditional on the discriminator, which most databases can't express directly), and can approach practical column-count limits. ## Class Table Inheritance Class Table Inheritance instead gives the base class its own table (`employees`, holding `name`, `hire_date`, and the shared primary key) and gives each subclass its own table holding only its additional columns (`salaried_employees` with `annual_salary`, `hourly_employees` with `hourly_rate` and `hours_per_week`), where each subclass table's primary key is also a foreign key back to the base table's primary key - a direct application of the Identity Field pattern shared across the join. - **This keeps the schema normalized**: no column is ever null because it belongs to a different subclass, since a row simply doesn't exist in a subclass table it doesn't belong to. - **The cost is joins**: loading a fully-typed Salaried employee requires joining `employees` to `salaried_employees`, and a polymorphic query across the whole hierarchy (all employees, whichever subclass) requires an outer join to every subclass table, or a strategy of always querying the base table and lazily joining subclass details only when the specific subclass is known - more query complexity and more round trips or larger joins than Single Table Inheritance. ## Concrete Table Inheritance Concrete Table Inheritance instead gives each concrete subclass its own completely self-contained table - `salaried_employees` with `name`, `hire_date`, and `annual_salary` all present, and `hourly_employees` with `name`, `hire_date`, `hourly_rate`, and `hours_per_week` all present - with no shared base table at all. - **Loading a known-subclass instance** needs no join whatsoever, and every column in every table is meaningfully non-null for that subclass. - **The costs are schema duplication** (`name` and `hire_date` are physically repeated in both tables, so a schema change to a base-class column means altering every subclass table individually and keeping them in sync) and the loss of a natural place to enforce identity uniqueness across the whole hierarchy (two different subclass tables could theoretically reuse the same primary key value, since there's no shared sequence enforcing hierarchy-wide uniqueness unless deliberately set up). - **Polymorphic queries** across the hierarchy are the most awkward here: since there's no shared table, 'all employees' has to be a `UNION` (or `UNION ALL`) across every subclass table, projecting only the common columns. ## Choosing between them In practice, the choice tracks how deep and volatile the hierarchy is and how often polymorphic queries are needed versus subclass-specific ones. 1. **Single Table Inheritance** is the default in frameworks like Hibernate/JPA (`@Inheritance(strategy = SINGLE_TABLE)`) precisely because it's simplest and fastest for shallow hierarchies with few subclass-specific columns and frequent polymorphic access - a classic real-world example is a Payment hierarchy (CreditCardPayment, BankTransferPayment, PayPalPayment) in an e-commerce system, where reporting queries routinely need 'all payments' regardless of type. 2. **Class Table Inheritance** is favored when subclasses diverge significantly and normalization matters more than join cost, or when different subclasses are owned/evolved by different teams. 3. **Concrete Table Inheritance** is the least commonly chosen of the three in ORMs (it maps awkwardly to a single shared identity space) but shows up naturally in systems that never needed polymorphic queries in the first place and instead grew independent, subclass-specific tables that only later got treated as a conceptual hierarchy.