Hibernate лучший подход для одного класса Java и нескольких таблиц? - PullRequest
4 голосов
/ 09 марта 2010

Другими словами: как вы моделируете / отображаете сильно повторно используемый дочерний класс / таблицу для множества различных родительских сущностей?

У меня есть несколько типов сущностей, каждый из которых сохраняется в своей таблице:

класс A -> таблица A класс B -> таблица B ....

Теперь мне нужно сделать каждый из этих классов родителем однонаправленной дочерней коллекции 1: M. Коллекция представляет собой историю одобрений, которые предприятие получило с течением времени. Класс дочернего домена называется «ApprovalItem». Класс Approval одинаков для всех типов родителей.

Каков наилучший способ отобразить это? Если я создаю одну таблицу для хранения всех ApprovalItems, то я не могу навязать отношение FK к PK объекта и / или у меня плохой дизайн базы данных.

С другой стороны, я мог бы создать таблицу ApprovalIems для каждого типа сущности (например, A_ApprovalItems, B_ApprovalItems и т. Д.). Это похоже на хорошую схему на стороне базы данных, но затем мне кажется, что мне нужно создать отдельные классы домена в Java для каждого утверждения сущности (например, класс AAprrovalItem, класс BApprovalItem и т. Д.). Это создает много хлопот и сложностей для создания такого большого количества новых классов в Java, которые не делают ничего, кроме того, что позволяют мне добавлять различные аннотации сопоставления JPA.

Есть ли в Hibernate метод сопоставления, который позволит мне иметь один класс в Java-карте для нескольких разных таблиц в зависимости от того, кто является родительским владельцем коллекции?

Ответы [ 2 ]

3 голосов
/ 09 марта 2010

Я мог бы создать таблицу ApprovalItem для каждого типа объекта (например, A_ApprovalItem, B_ApprovalItem и т. Д.). Это похоже на хорошую схему на стороне базы данных

Но

Кажется, мне нужно создать отдельные классы домена в Java для каждого утверждения сущности (например, класс AAprrovalItem, класс BApprovalItem и т. Д.).

Тебе это не нужно. Вы можете создать один класс ApprovalItem и создать связь @OneToMany между родительскими классами и ApprovalItem. Hibernate заботится о создании связанной таблицы для каждого отношения.

@Entity
public class ClassA {

    @Id
    @GeneratedValue 
    private Integer id;

    // Hibernate will create CLASSA_APPROVALITEM to link both class
    @OneToMany
    private List<ApprovalItem> approvalItemList;

}

@Entity
public class ClassB {

    @Id
    @GeneratedValue 
    private Integer id;

    // Hibernate will create CLASSB_APPROVALITEM to link both class
    @OneToMany
    private List<ApprovalItem> approvalItemList;

}

И ваш класс ApprovalItem

@Entity
public class ApprovalItem {

    @Id
    @GeneratedValue 
    private Integer id;

    // Nothing else

}

Но давайте посмотрим, что говорит об этом Java Persistence с книгой Hibernate

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

Так что имейте это в виду при работе с общими ссылками.

Чтобы увидеть, как выглядит целевая схема, вы можете использовать следующее

AnnotationConfiguration configuration = new AnnotationConfiguration();

configuration
    .addAnnotatedClass(ClassA.class)
    .addAnnotatedClass(ClassB.class)
    .addAnnotatedClass(ApprovalItem.class)
    .setProperty(Environment.USER, <TYPE_YOUR_USER>)
    .setProperty(Environment.PASS, <TYPE_YOUR_PASSWORD>)
    .setProperty(Environment.URL, <TYPE_YOUR_URL>)
    .setProperty(Environment.DIALECT, <TYPE_YOUR_DIALECT>)
    .setProperty(Environment.DRIVER, <TYPE_YOUR_DRIVER>);

SchemaExport schema = new SchemaExport(configuration);
schema.setOutputFile("schema.sql");

schema.create(<DO_YOU_WANT_TO_PRINT_TO_THE_CONSOLE>, <DO_YOU_WANT_TO_EXPORT_THE_SCRIPT_TO_THE_DATABASE>);

Будет сгенерирован файл с именем schema.sql, содержащий вашу целевую схему

С уважением,

2 голосов
/ 09 марта 2010

Глава 8. Отображение наследования документации Hibernate может помочь.

В противном случае, я не вижу проблем с несколькими производными классами ApprovalItem, которые, как вы говорите, «ничего не делают», поскольку они дифференцируют Утверждение, это похоже на тип утверждения. Рассматривая вашу модель таким образом, я бы рекомендовал использовать несколько классов, даже если они наследуются только от вашего базового класса ApprovalItem.

Хорошо ли я понял ваш вопрос или мне не хватает чего-то более тонкого?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...