What is the Single Table Inheritance Pattern?
Single Table Inheritance explained — one shared table, discriminator columns, trade-offs vs class table inheritance, with a JPA Java example.
Expected Interview Answer
Single Table Inheritance is a pattern for mapping an object-oriented class hierarchy to a relational database by storing every class in the hierarchy — the base class and all its subclasses — in one single database table, using a discriminator column to record which subclass each row actually represents.
Each row in the shared table contains a union of every column needed by any subclass, so columns that only apply to one subclass sit empty (null) for rows representing the other subclasses. A discriminator column, often literally named “type” or “kind,” tells the object-relational mapping layer which subclass to instantiate when reading a row back. The pattern’s main appeal is simplicity and read performance: fetching a polymorphic collection of the base type requires only one table and no joins at all. The trade-offs are real: the table accumulates many nullable columns as subclasses grow, and non-null database constraints become hard to enforce per-subclass since the same column can be required for one type and irrelevant for another. Alternatives in the same family include Class Table Inheritance (one table per class, joined) and Concrete Table Inheritance (one table per concrete class, no shared table), each trading off differently between query simplicity, storage waste, and schema flexibility.
- Fetching polymorphic collections requires no joins at all
- Simplest schema to reason about for shallow hierarchies
- Fast reads since all data for any subclass sits in one table
- Straightforward to implement with most ORMs (e.g. JPA’s SINGLE_TABLE strategy)
AI Mentor Explanation
A single master scorebook records every player on the roster — batters, bowlers, wicketkeepers, all-rounders — on the same set of rows, with a “role” column marking which type each row is. A pure bowler’s row leaves the batting-average columns blank, and a specialist batter’s row leaves the bowling-economy columns blank, but everyone lives in the one book. That single shared table with a role discriminator and unused columns per row is exactly the single table inheritance pattern applied to a class hierarchy.
Step-by-Step Explanation
Step 1
Identify the class hierarchy
A base class (e.g. Vehicle) with several subclasses (Car, Truck, Motorcycle).
Step 2
Design one shared table
Create a single table containing the union of all columns needed across the base class and every subclass.
Step 3
Add a discriminator column
Include a “type” (or similarly named) column that stores which subclass each row represents.
Step 4
Map ORM classes to the table
Configure the ORM (e.g. JPA’s @Inheritance(strategy = SINGLE_TABLE)) so it reads the discriminator to instantiate the correct subclass.
What Interviewer Expects
- Correct definition: one shared table, discriminator column, union of subclass columns
- Awareness of the trade-off: simple/fast reads versus many nullable columns
- Comparison to alternatives (class table inheritance, concrete table inheritance)
- Knowledge of at least one real ORM mechanism (e.g. JPA @DiscriminatorColumn)
Common Mistakes
- Confusing single table inheritance with class table inheritance (one table per class, joined)
- Not mentioning the discriminator column as the mechanism distinguishing rows
- Failing to note the nullable-column trade-off as the pattern grows
- Assuming the pattern applies to unrelated tables rather than an actual class hierarchy
Best Answer (HR Friendly)
“Single table inheritance is a way to store an entire class hierarchy — a base class and all its subclasses — in just one database table, with a discriminator column that records which subclass each row actually represents. It keeps reads simple and fast because there are no joins needed, but the trade-off is that the table ends up with a lot of columns that are only relevant to some subclasses and stay empty for others.”
Code Example
@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "vehicle_type")
abstract class Vehicle {
@Id @GeneratedValue
Long id;
String make;
}
@Entity
@DiscriminatorValue("CAR")
class Car extends Vehicle {
int doorCount; // stored, but null for Motorcycle rows
}
@Entity
@DiscriminatorValue("MOTORCYCLE")
class Motorcycle extends Vehicle {
boolean hasSidecar; // stored, but null for Car rows
}
// All Car and Motorcycle rows live in one shared "vehicle" table,
// distinguished by the "vehicle_type" discriminator column.Follow-up Questions
- How does single table inheritance compare to class table (joined) inheritance?
- What happens to NOT NULL constraints for columns that only apply to one subclass?
- When would you choose single table inheritance over concrete table inheritance?
- How does JPA’s @DiscriminatorColumn map to the actual subclass at query time?
MCQ Practice
1. In single table inheritance, how is a row’s subclass identified?
A dedicated discriminator column stores which subclass each row represents.
2. What is the main structural trade-off of single table inheritance as a hierarchy grows?
Every subclass-specific column is added to the shared table, leaving it null for rows of other subclasses.
3. Compared to class table inheritance (one table per class, joined), single table inheritance offers?
Single table inheritance avoids joins entirely for polymorphic reads, at the cost of nullable columns and looser constraints.
Flash Cards
Single table inheritance, one line? — An entire class hierarchy stored in one table, with a discriminator column marking each row’s subclass.
Main benefit? — Polymorphic reads need no joins — fast and simple.
Main trade-off? — Many nullable columns accumulate as more subclasses are added.
Key alternative? — Class table inheritance — one table per class, joined by a shared key.