В иерархии сущностей JPA с помощью InheritanceType.JOINED, все отношения с подклассов приводит ограничений внешнего ключа на таблицу суперкласса

Question

У меня есть следующие JPA 2.0 Entities

@Entity 
@Inheritance(strategy= InheritanceType.JOINED) 
public abstract class BookKeepingParent implements Serializable { 
    @Id 
    protected Long Id; 
    ... 
} 

@Entity 
public class Employee extends BookKeepingParent { 
    private String name; 

    @ManyToOne 
    private Role role; 
    ... 
} 

@Entity 
public class Role extends BookKeepingParent { 
    private String name; 
    ... 
} 

Я хочу, чтобы JPA генерировать таблицы для меня, поскольку он упрощает установку в нескольких местах. Я обычно ожидал, что для создания этого:

CREATE TABLE bookkeepingparent (
    id bigint NOT NULL, 
    dtype character varying(31), 
    CONSTRAINT bookkeepingparent_pkey PRIMARY KEY (id) 
) 

CREATE TABLE role (
    id bigint NOT NULL, 
    name character varying(255), 
    CONSTRAINT role_pkey PRIMARY KEY (id), 
    CONSTRAINT fk_role_id FOREIGN KEY (id) REFERENCES bookkeepingparent (id) 
) 

CREATE TABLE employee (
    id bigint NOT NULL, 
    name character varying(255), 
    role_id bigint, 
    CONSTRAINT employee_pkey PRIMARY KEY (id), 
    CONSTRAINT fk_employee_id FOREIGN KEY (id) REFERENCES bookkeepingparent (id), 
    CONSTRAINT fk_employee_role_id FOREIGN KEY (role_id) REFERENCES role (id) 
) 

Первые две таблицы, где же, но она породила employee стол таким образом:

CREATE TABLE employee (
    id bigint NOT NULL, 
    name character varying(255), 
    role_id bigint, 
    CONSTRAINT employee_pkey PRIMARY KEY (id), 
    CONSTRAINT fk_employee_id FOREIGN KEY (id) REFERENCES bookkeepingparent (id), 
    CONSTRAINT fk_employee_role_id FOREIGN KEY (role_id) REFERENCES bookkeepingparent (id) 
) 

Вы можете заметить, что fk_employee_role_id ссылается на bookkeepingparent стол, вместо таблицы role. У меня есть большая иерархия сущностей JPA, и я хочу, чтобы бухгалтерский учет был суперклассом большинства из них. Это в первую очередь из-за некоторых очень специфических стратегий генерации идентификаторов и других видов ведения бухгалтерского учета. Этот дизайн помогает сохранить весь этот код хранения книг отдельно от функционального кода и позволить программистам, работающим над функциональным кодом, не беспокоиться об этом.

Все это работало нормально, пока не выросло количество столов. Теперь мы видим, что для всех отношений ManyToOne и OneToOne JPA генерирует внешние ключи, относящиеся к родительской таблице. С 200 нечетными таблицами вставки уже медленны, потому что все ограничения внешнего ключа относятся к элементу bookekeepingparent, и каждый объект, когда он сохраняется в первый раз, вставляется в родительскую таблицу бухгалтерии. Кажется, я проверяю около 150 нечетных ограничений.

Итак, следующие вопросы: почему JPA это делает? Является ли это стандартным поведением JPA? (Я использую EclipseLink). Если я вручную изменю схему БД, их любые подводные камни ожидать?

Это мой первый вопрос о StackOverflow, я старался изо всех сил искать любые существующие ответы. Извиняюсь, если я пропустил. Благодарю.

Answer 1

Вы используете объединенное наследование, а это означает, что для каждого класса таблица учета является основной таблицей, а любая таблица подкласса является вторичной. Первичный ключ для подклассов наследуется от родителя, а внешние ключи должны ссылаться на идентификатор, поэтому все будут ссылаться на идентификатор в бухгалтерском учете, подготовленный по дизайну. Различные поставщики позволяют ссылаться на не-pk-поля, но это может вызвать проблемы, поскольку для разрешения ссылок могут потребоваться хиты базы данных вместо использования кеша.

Ограничения базы данных не связаны с JPA, поэтому вы можете изменять их по мере необходимости и не влиять на приложение, если обновления и удаления вложений по-прежнему будут соответствовать.