Какие стратегии маппинга наследования существуют в Hibernate
Что проверяют
Знаете ли вы четыре варианта и понимаете ли, чем каждый платит.
Как отвечать
1. Одна таблица на иерархию. Все классы в одной таблице, тип строки определяется колонкой-дискриминатором. Стратегия по умолчанию.
Плюсы: самые быстрые запросы, никаких соединений, полиморфные выборки тривиальны.
Минус принципиальный: колонки подклассов обязаны допускать пустое значение, потому что у строк другого типа их нет. Значит ограничение обязательности на уровне базы поставить нельзя, и целостность держится только на коде. При большом числе подклассов таблица превращается в широкую разреженную простыню.
2. Таблица на класс с соединением. У каждого класса своя таблица, у подклассов только их поля плюс внешний ключ на таблицу родителя.
Плюсы: нормализованная схема, обязательность колонок работает.
Минус: каждый запрос к подклассу требует соединения, а полиморфная выборка соединяет все таблицы иерархии. На глубокой иерархии это заметно.
3. Таблица на конкретный класс. У каждого неабстрактного класса своя полная таблица со всеми колонками, включая унаследованные.
Плюсы: запрос к конкретному типу без соединений.
Минусы серьёзные: полиморфная выборка превращается в объединение всех таблиц, а генерация идентификаторов усложняется, потому что автоинкремент в каждой таблице свой и уникальность по иерархии не гарантирована. Применяется редко.
4. Общий суперкласс без сущности. Родитель не является сущностью, он просто переиспользует поля: идентификатор, метки времени, версия. Полиморфные запросы по нему невозможны, потому что такого типа для ORM не существует. Это самый частый практический случай: общая база для всех сущностей проекта.
Правило выбора: по умолчанию первая стратегия, вторая когда подклассы сильно различаются и важна целостность на уровне базы, четвёртая когда наследование нужно только ради общих полей.
Где спотыкаются
Берут стратегию с соединениями и удивляются числу запросов.
Ставят обязательность на колонку подкласса в общей таблице.
Путают общий суперкласс с полноценной сущностью.
Строят иерархию из пяти уровней вместо композиции.