Отображение иерархии JPA‑сущностей в таблицах БД

Один явный вариант — JOINED: общие поля User находятся в корневой таблице, а поля каждого подтипа — в его таблице с тем же ключом. Admin наследует данные и User, и Employee.

Короткий ответ

Что ответить на собеседовании

Один явный вариант — 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.

ИИ-помощник для собеседований

Хочешь уверенно проходить собеседования?

Попробуй ИИ-помощник для собеседований: слышит вас и собеседника, анализирует экран, подсказывает ответы в реальном времени, работает без VPN и не попадает в захват экрана.

Подробнее