Один явный вариант — JOINED: общие поля User находятся в корневой таблице, а поля каждого подтипа — в его таблице с тем же ключом. Admin наследует данные и User, и Employee.
Отображение иерархии JPA‑сущностей в таблицах БД
Один явный вариант — JOINED: общие поля User находятся в корневой таблице, а поля каждого подтипа — в его таблице с тем же ключом. Admin наследует данные и User, и Employee.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Условие
В примере показана наследственная связь между сущностями User, Customer, Employee и Admin. Требуется смоделировать эту иерархию JPA‑сущностей так, чтобы она корректно реализовывалась на уровне базы данных.
@Entity class User { int field1; ... }
@Entity class Customer extends User { int field2; ... }
@Entity class Employee extends User { int field3; ... }
@Entity class Admin extends Employee { int field4; ... }
Ответ
Один явный вариант — JOINED: общие поля User находятся в корневой таблице, а поля каждого подтипа — в его таблице с тем же ключом. Admin наследует данные и User, и Employee.
На User укажите @Entity, @Id и @Inheritance(strategy = InheritanceType.JOINED); остальные классы сохраняют @Entity. Получатся User(id,field1), Customer(id,field2), Employee(id,field3), Admin(id,field4), где ключи подтипов связаны с родителями. Нужны корректные конструкторы и mapping имён. Без явного выбора действует SINGLE_TABLE. JOINED уменьшает дублирование полей, но требует joins при чтении подтипов.
Источник: jakarta.ee.