Какую стратегию наследования выбирали с аннотацией Inheritance

Что проверяют

Знаете ли вы три стратегии отображения иерархии сущностей в JPA и умеете ли выбрать по профилю запросов, а не по вкусу. Следом обычно спрашивают, какой SQL Hibernate сгенерирует на полиморфный запрос и чем @Inheritance отличается от @MappedSuperclass.

Как отвечать

Аннотация @Inheritance (в Spring Boot 3 это jakarta.persistence.Inheritance) ставится на корневую сущность, стратегия задаётся через InheritanceType. Если стратегию не указать, будет SINGLE_TABLE.

• SINGLE_TABLE: вся иерархия в одной таблице, тип строки хранит колонка-дискриминатор (по умолчанию DTYPE, настраивается через @DiscriminatorColumn и @DiscriminatorValue). Полиморфный запрос идёт без JOIN, это самый быстрый вариант. Цена: колонки подклассов обязаны быть nullable, простой NOT NULL не поставить, остаётся CHECK по дискриминатору;
• JOINED: таблица для полей родителя и по таблице на каждый подкласс, связанные по первичному ключу. Схема нормализована, ограничения работают, но вставка пишет в несколько таблиц, а запрос по базовому типу соединяет все таблицы подклассов;
• TABLE_PER_CLASS: у каждого конкретного класса своя полная таблица. Запрос к конкретному типу простой, полиморфный превращается в UNION ALL. Генерация IDENTITY здесь не подходит, id должны быть уникальны по всем таблицам, нужен SEQUENCE.

Выбор объясняйте на своём проекте: мало специфичных полей и частые запросы по базовому типу дают SINGLE_TABLE; много своих полей и важны ограничения, тогда JOINED; полиморфные запросы не нужны, тогда часто хватает @MappedSuperclass, который вообще не создаёт иерархию сущностей.

Где спотыкаются

Путают @Inheritance из JPA с @Inherited из java.lang.annotation. Вторая про наследование самих аннотаций подклассами и к базе отношения не имеет.

Называют JOINED лучшим «потому что нормализация» и молчат про стоимость соединений. На иерархии из пяти подклассов findAll() по базовому типу заметно бьёт по производительности.

Не знают, что стратегия меняется только миграцией данных. Переезд с SINGLE_TABLE на JOINED на живой базе означает перенос строк по таблицам, а не правку одной аннотации.