What is the Class Table Inheritance Pattern?
Class Table Inheritance explained — one table per class joined by a shared key, versus Single and Concrete Table Inheritance, with examples.
Expected Interview Answer
Class Table Inheritance is an object-relational mapping pattern where every class in an inheritance hierarchy, including abstract ones, gets its own database table holding only the fields it introduces, and rows are joined by a shared primary key to reconstruct a full object.
A base class such as "Employee" gets a table with shared columns like id and name, while subclasses such as "Manager" and "Engineer" get their own tables containing only their own extra columns, keyed by the same id as a foreign key back to the base table. Loading a Manager means joining the Employee table with the Manager table on that shared id. This keeps the schema normalized and avoids the sparse, nullable columns that Single Table Inheritance produces, but it costs extra joins on every read and gets slower as the hierarchy grows deeper. It sits between Single Table Inheritance (one wide table) and Concrete Table Inheritance (one denormalized table per concrete class, no joins) as the three classic Fowler ORM strategies.
- Normalized schema with no nullable “foreign” columns
- Adding a new subclass only adds a new table, not new columns everywhere
- Storage is proportional to actual fields used per type
- Database constraints map cleanly to the class hierarchy
AI Mentor Explanation
A cricket board keeps one master register of every registered player with just name and player ID, then separate specialist ledgers for batters, bowlers and wicketkeepers, each ledger holding only the stats specific to that role and referencing the same player ID. To pull a full profile for an all-rounder you look them up in the batting ledger and the bowling ledger and stitch the rows together using that shared ID. This mirrors class table inheritance: a shared base table plus one table per subtype, joined on a common key rather than one giant sheet with blank columns for roles that don’t apply.
Step-by-Step Explanation
Step 1
Create the base table
One table for the root class holding the primary key and shared fields common to every subtype.
Step 2
Create one table per subclass
Each subtype gets its own table containing only the fields it uniquely introduces.
Step 3
Share the primary key across tables
Every subtype table uses the same id value as a primary key and foreign key back to the base table.
Step 4
Join on read
Loading a full object requires joining the base table with the appropriate subtype table(s) on that shared key.
What Interviewer Expects
- Correct contrast with Single Table Inheritance and Concrete Table Inheritance
- Understanding that the join happens on a shared primary key
- Awareness of the join-cost tradeoff versus schema normalization
- Knowledge that abstract base classes still get their own table in this pattern
Common Mistakes
- Confusing Class Table Inheritance with Single Table Inheritance (one wide table)
- Forgetting that every level of the hierarchy needs a join to fully materialize an object
- Not mentioning the performance cost of deep hierarchies requiring many joins
- Assuming this pattern eliminates nulls entirely rather than just reducing them
Best Answer (HR Friendly)
“Class Table Inheritance is a way of storing an inheritance hierarchy in a relational database by giving each class its own table, connected by a shared ID. So a base Employee table holds common fields, and a Manager table holds only manager-specific fields, joined together when you need the full picture. It keeps the schema clean and avoids empty columns, at the cost of needing joins every time you read a subtype.”
Code Example
// employee (id, name, hire_date)
// manager (employee_id FK -> employee.id, team_size)
// engineer (employee_id FK -> employee.id, primary_language)
class EmployeeRepository {
Manager loadManager(long id) {
String sql =
"SELECT e.id, e.name, m.team_size " +
"FROM employee e JOIN manager m ON e.id = m.employee_id " +
"WHERE e.id = ?";
// execute sql, map row to Manager(id, name, teamSize)
return runQueryAndMap(sql, id);
}
}
class Manager {
long id;
String name;
int teamSize;
Manager(long id, String name, int teamSize) {
this.id = id; this.name = name; this.teamSize = teamSize;
}
}Follow-up Questions
- How does Class Table Inheritance differ from Single Table Inheritance?
- What happens to query performance as the hierarchy gets deeper?
- How would an ORM like Hibernate configure this mapping strategy?
- When would Concrete Table Inheritance be a better fit than Class Table Inheritance?
MCQ Practice
1. In Class Table Inheritance, how are rows for a subclass connected to the base class row?
The subclass table reuses the base table’s primary key as its own key and foreign key, enabling a join.
2. What is the main performance cost of Class Table Inheritance?
Every read of a subtype requires joining the base table with one or more subtype tables.
3. Which ORM pattern uses one single wide table for the whole hierarchy instead?
Single Table Inheritance stores every subclass’s fields in one table, using nullable columns for fields that don’t apply.
Flash Cards
Class Table Inheritance in one line? — Each class in the hierarchy gets its own table, joined by a shared primary key.
Main tradeoff? — Normalized schema with fewer nulls, but extra joins on every read.
Contrast with Single Table Inheritance? — Single Table uses one wide table with nullable columns for every subtype field.
Contrast with Concrete Table Inheritance? — Concrete Table denormalizes fully — one table per concrete class with base fields duplicated, no joins needed.