Всегда ли мне нужно создавать отдельный класс для многих отношений в спящем режиме

Question

Я читал эту статью

http://www.mkyong.com/hibernate/hibernate-many-to-many-relationship-example/

Но он создал три класса

Stock
Category
stock_category

Всегда ли мне нужна отдельная таблица для отношений или это можно сделать в 2 таблицах, также как и в наличии, Категория

Answer 1

У вас есть отношение многие ко многим, вам понадобится таблица базы данных соединений, в вашем случае таблица Stock_Category.Тем не менее, эта таблица соединений может не отображаться в виде объекта Hibernate, в зависимости от того, чего вы пытаетесь достичь.

Если ваша таблица соединений содержит только первичные ключи из таблицы Stock и таблицы Category, то вы можете использовать @ManyToMany.В этом случае сущность Stock будет иметь stock.getCategories(), которая возвращает все категории, а сущность Category будет иметь category.getStocks(), которая возвращает все акции.Соединительная таблица не отображается вообще.

Однако, если вы собираетесь использовать дополнительные поведения в таблице Stock_Category, например, если вы хотите определить, кто назначает запас категорииили когда он добавлен, вам нужно будет использовать @OneToMany и @ManyToOne вместо @ManyToMany.В этом случае соединительная таблица будет отображаться как объект Hibernate.Таким образом, сущность Stock будет иметь stock.getStockCategories(), которая возвращает все категории акций, а сущность Category также может иметь stock.getStockCategories() (если вы настраиваете двунаправленное отношение), которая возвращает ту же самую вещь.Сущность StockCategory содержит дополнительные свойства, такие как personWhoAddsTheStockIntoCategory или dateAdded и т. Д. *

Надеюсь, это поможет.

Answer 2

Нет.Никогда.Это общий вопрос, который я слышал от многих людей.И ответ таков: когда вы проектируете объекты:

Вы НЕ ДОЛЖНЫ мыслить с точки зрения отношений (RDBMS), но вы должны думать с точки зрения объектов (Java) .

Более подробно.Hibernate пытается решить довольно сложную задачу: связать объектно-ориентированную вселенную Java с реляционным миром.В большинстве случаев это достигается за счет путаницы между двумя парадигмами.

Лучшая стратегия (и менее болезненная) состоит в том, чтобы спроектировать ваши сущности и позволить Hibernate создать схему для вас.Таким образом, предполагая, что

Stock entity refers to many categories (Set of Categories)
and
Category entity has a set of Stock ids

У нас есть отношение «многие ко многим», доступное из обеих сущностей. И вам нужны только два класса здесь .

Затем вам нужно аннотировать (здесь я предполагаю, что вы используете аннотации, а не .hbm.xml) эти наборы как атрибуты многие-ко-многим (читай Руководство по Hibernate ).

Скомпилируйте код.Затем Настройте Hibernate для автоматической генерации схемы (hbm2ddl.auto - это свойство, которое включает генерацию схемы).Если все в порядке, вы увидите 3 таблицы в базе данных, 2 таблицы для сущностей и 1 таблицу для ассоциации «многие ко многим» (это третья нормальная форма схемы, например, самая чистая).

Тогда сохраняйте некоторые сущности и наслаждайтесь.И никогда не забывайте Думайте в терминах ОО при использовании гибернации (нет операции JOIN) .

Answer 3

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

В коде цитируемой статьи Stock и Category оба имеют поля Set<StockCategory>, сопоставленные с аннотацией @OneToMany. Вместо этого вы можете использовать аннотации @ManyToMany и полностью избегать класса StackCategory. Таблица по-прежнему должна существовать и на нее будет ссылаться аннотация @JoinTable на одном конце отношения.

См. документы по сопоставлению ассоциаций для получения дополнительной информации о том, как это сделать.

Answer 4

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