Связи вида многие-ко-многим между двумя таблицами в СУБД создаются с помощью третьей таблицы. Hibernate позволяет не создавать отдельную сущность для соединительной таблицы, а описать её в аннотации @JoinTable. У такой таблицы есть свои ограничения: она содержит только колонки со ссылками на другие таблицы и не содержит других колонок.
Читать далееДвунаправленная связь многие-ко-многим через дополнительную сущность в Hibernate
Связь вида многие-ко-многим между сущностями проще всего организовать через промежуточную сущность. Такой подход соответствует тому, как создаются связи многие-ко-многим между таблицами в БД. Связующая таблица в таком случае помимо колонок, ссылающихся, на связываемые таблицы, также может иметь любые другие дополнительные колонки.
Читать далееИспользование отображений (Map) для связи @OneToMany один-ко-многим между сущностями
При создании связи один-ко-многим между сущностями в качестве коллекции, ссылающейся на сущности, которых «много», помимо обычных списков (List) и множеств (Set), также можно использовать отображения (Map). Это позволяет значения любого (обычно уникального) поля вынести в ключ отображения, а в значение положить саму сущность. Что бывает удобно при некоторых обстоятельствах.
Читать далееСвязь @OneToMany между @Embeddable и @Entity классами в Hibernate
Встраиваемый (@Embeddable) класс может содержать поле со списком объектов класса-сущности (@Entity). При этом у данных встраиваемого класса нет своей таблицы и они, как и положено, хранятся в таблице какой-то ещё сущности. Такая организация приводит к возникновению связи один-ко-многим между таблицами классов сущностей, которые в коде напрямую друг с другом не связаны.
Например, если у нас класс-сущность Company, содержащий поле встраиваемого класса Address при этом в классе Address есть поле List<Person> owners, где Person это в свою очередь класс-сущность, то между таблицами COMPANY и PERSON создаётся связь один-ко-многим, хотя между классами Company и Person прямой связи нет.
Читать далееДвунаправленная связь @OneToMany через таблицу (@JoinTable) в Hibernate
В JPA/Hibernate есть несколько способов описания двунаправленной связи между сущностями. Одним из которых является связь через третью таблицу. Если сущности слабо связаны друг с другом и связи между ними не постоянны, то такой подход подход позволяет избежать null значений в таблицах.
Например, если у нас есть две сущности: Person и Email, которые достаточно независимы друг от друга в том смысле, что не за каждым человеком закреплён адрес почты, а также не про каждый адрес известно чей он, то при создании связи через простой внешний ключ некоторые поля будут содержать null. Если такая ситуация недопустима, то организация связи через третью таблицу, эту проблему решает. Цена решения — затраты на join’ы при выборке.
Читать далееОднонаправленная связь @OneToMany между сущностями в Hibernate
Создание связи один-ко-многим является типичной задачей. Главным отличием описания такой связи в JPA/Hibernate от описания в БД заключается в том, что если в БД мы всегда описываем связь в ссылающейся таблице, то в Hibernate — это можно сделать в той сущности, на которую ссылаются.
Например, допустим у нас есть человек и у него есть адреса электронной почты. Тогда в БД в таблице EMAIL мы опишем колонку с внешним ключом на таблицу PERSON. Hibernate же позволяет в классе Person создать поле List<Email> emails и, аннотировав его должным образом, описать аналогичную связь. Класс Email же будет описан таким образом, как будто бы он вообще никак не связан с классом Person. Хотя в БД мы по-прежнему получим таблицу EMAIL с внешним ключом на PERSON.
Читать далееСоздание однонаправленной связи один-к-одному со связыванием через третью таблицу
Не всегда можно и имеет смысл расширять ту или иную таблицу за счёт добавления в неё новых полей. Зачастую удобней и правильней создать ещё одну таблицу и установить между ними связь типа один-к-одному.
Если сущности слабо связаны друг с другом и не могут опираться на разделяемые значения первичных ключей, то связь между ними можно организовать либо с помощью внешних ключей, либо с помощью промежуточной таблицы. Если мы не можем допустить наличия NULL значений в таблице, то вариант с внешним ключом может не подойти и необходимо использовать третью таблицу для связи.
Читать далееСоздание однонаправленной связи один-к-одному со связыванием через внешний ключ
Не всегда можно и имеет смысл расширять ту или иную таблицу за счёт добавления в неё новых полей. Зачастую удобней и правильней создать ещё одну таблицу и установить между ними связь типа один-к-одному.
Если сущности слабо связаны друг с другом и не могут опираться на разделяемые значения первичных ключей, то связь между ними можно организовать с помощью внешнего ключа.
Читать далееСоздание двунаправленной связи один-к-одному с общим значением поля ID обоих сущностей, устанавливаемым автоматически
Не всегда можно и имеет смысл расширять ту или иную таблицу за счёт добавления в неё новых полей. Зачастую удобней и правильней создать ещё одну таблицу и установить между ними связь типа один-к-одному. В БД связь может поддерживаться через общие значения первичных ключей. Аналогично необходимо создать подобную связь между отображаемыми в эти таблицы сущностями.
Такую связь можно сделать двунаправленной. И расширяющая, и расширяемая сущности в таком случае ссылаются друг на друга. Кроме того, если связь двунапрвленная и JPA провайдером в проекте является Hibernate, то можно значительно облегчить создание общего ID и сохранение связанных сущностей в БД.
Читать далееСоздание однонаправленной связи один-к-одному с общим значением поля ID обоих сущностей
Не всегда можно и имеет смысл расширять ту или иную таблицу за счёт добавления в неё новых полей. Зачастую удобней и правильней создать ещё одну таблицу и установить между ними связь типа один-к-одному. В БД связь может поддерживаться через общие значения первичных ключей. Аналогично необходимо создать подобную связь между отображаемыми в эти таблицы сущностями.
Проще всего сделать такую связь однонаправленной. Расширяемая сущность в таком случае не содержит поля, ссылающегося на расширяющую. Она может иметь несколько расширяющих сущностей/таблиц и «не знать» об этом. Расширяющая сущность связывается с расширяемой с помощью аннотации @OneToOne.
Читать далее