JPA's @Inheritance annotation offers SINGLE_TABLE, JOINED and TABLE_PER_CLASS. Describe the table layout each one produces and the main trade-off of each.

## The problem Java has inheritance; relational tables do not. `@Inheritance(strategy = ...)` on the root entity chooses how a class hierarchy is projected onto tables. Take `Payment` (base) with `CardPayment` and `BankTransfer` as subclasses. ## SINGLE_TABLE — one table, a discriminator ``` payment(id, amount, currency, payment_type, card_number, expiry, iban, bic) ``` Every row of every subclass lives here. A **discriminator column** (`payment_type` by default `DTYPE`, a `VARCHAR`) records the concrete type so Hibernate can instantiate the right class. *Reads*: `SELECT * FROM payment WHERE id = ?` — one statement, no joins, whether you asked for `Payment` or `CardPayment`. Polymorphic queries add at most a discriminator predicate. This is the fastest strategy, by a wide margin, and it is the **default** when you specify no strategy. *Writes*: a single INSERT. *The cost*: `card_number` is meaningless for a bank transfer, so it must be nullable. You therefore **lose database-level `NOT NULL`** on every subclass-specific column; the only enforcement left is Bean Validation in the application. With many subclasses the table grows wide and sparse. Column-name collisions between sibling subclasses must be resolved by hand. ## JOINED — a table per class, joined by primary key ``` payment(id, amount, currency) card_payment(id -> payment.id, card_number, expiry) bank_transfer(id -> payment.id, iban, bic) ``` The subclass table's primary key is also a foreign key to the root table. This is the textbook normalized mapping: every column sits where it belongs, `NOT NULL` and unique constraints work, no wasted space, and a foreign key can reference `payment(id)` polymorphically. *Reads*: loading a `CardPayment` needs a join to `payment`. A polymorphic `SELECT p FROM Payment p` produces an outer join to **every** subclass table (Hibernate 6 typically emits one query with left joins, older versions sometimes used a union of joins), so the cost grows with the number of subclasses — the classic "my query joins nine tables" complaint. *Writes*: an INSERT per level (root plus subclass), and deletes likewise. `@PrimaryKeyJoinColumn` renames the join column when you do not want the inherited name. ## TABLE_PER_CLASS — one standalone table per concrete class ``` card_payment(id, amount, currency, card_number, expiry) bank_transfer(id, amount, currency, iban, bic) ``` Inherited columns are **duplicated** into each table; the abstract root usually gets no table at all. *Reads of one concrete type*: a single table, no joins — as fast as SINGLE_TABLE. *Polymorphic reads*: `SELECT p FROM Payment p` becomes a `UNION ALL` across every concrete table (Hibernate builds a synthetic "union subclass" view, padding missing columns with NULL literals). Cost and plan quality degrade quickly with the number of subclasses, and the optimizer often cannot push predicates as well as you would like. *Structural limitations*: identifiers must be unique **across** the whole hierarchy, because two rows in different tables both claiming id 1 would be the same `Payment`. That rules out `GenerationType.IDENTITY`; use a shared sequence or `TABLE` generation, or assigned UUIDs. And there is no single table for the base type, so **no foreign key can reference `Payment`** — any association to the base type must be modelled as a join table or duplicated per subtype. JPA marks support for this strategy as optional, though Hibernate implements it. ## How to choose - Subclasses add a handful of columns, read performance matters, hierarchy is shallow → **SINGLE_TABLE**. This is right far more often than its reputation suggests. - Subclasses add many columns, or the mandatory-ness of those columns must be enforced by the database, or the table would be embarrassingly sparse → **JOINED**. - You need per-type isolation and essentially never query the base type polymorphically → **TABLE_PER_CLASS**; often a sign the hierarchy is not really a hierarchy, and `@MappedSuperclass` may be the better fit. ## Things interviewers probe next - The strategy is declared on the **root** entity and applies to the whole hierarchy; you cannot mix per branch (Hibernate historically allowed some mixing via `@SecondaryTable`-like tricks, but the portable answer is: one strategy per hierarchy). - Under SINGLE_TABLE you can add `@DiscriminatorFormula` for legacy schemas that encode the type in an expression rather than a dedicated column. - A **nullable subclass column that should be mandatory** is the single most common production regret with SINGLE_TABLE; teams either accept Bean Validation only, or add a database CHECK constraint conditioned on the discriminator. - Under JOINED, deleting a base row must delete the subclass row too — Hibernate does it in the right order, but hand-written SQL against the schema will not. The strongest answer names the layout, the SQL shape (no join / join / union), and the one thing you lose in each: constraints, join cost, and polymorphic query cost respectively.