Использовали ли вы аннотацию Inheritance в проектах

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

Понимаете ли вы, как иерархия классов ложится на таблицы и чем платит каждый вариант. Формулировка «использовали ли вы» намекает, что ждут конкретный случай: какую стратегию выбрали и почему. Следом спрашивают, какой SQL Hibernate генерирует для полиморфного запроса по базовому классу.

Как отвечать

Сначала уточните, о какой аннотации речь: @Inheritance из JPA (пакет jakarta.persistence в современных версиях), а не java.lang.annotation.Inherited, которая управляет наследованием самих аннотаций. Затем три стратегии:

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

Отдельно упомяните @MappedSuperclass: общие поля вроде id и createdAt наследуются, но базовый класс не сущность и полиморфных запросов по нему нет.

Рассказ о своём опыте стройте так: какая была модель (например, платежи разных типов), какую стратегию выбрали, какая проблема проявилась со временем. Если аннотацию не применяли, скажите честно и объясните, какую стратегию взяли бы для конкретной модели и почему.

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

Утверждают, что JOINED ускоряет запросы. Он делает схему чище, а запросы как раз дороже, особенно на глубокой иерархии.

Берут наследование сущностей там, где хватило бы @MappedSuperclass или композиции, и получают сложные запросы без пользы.

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