Hibernate @Embedded против сопоставления ManyToOne

Question

Я пытаюсь создать отображение спящего режима между двумя таблицами User и Country, как показано ниже на изображении ниже.

Таблица Country используется только для пользователя, а не где-либо еще, поэтому следуетЯ использую Embedded и Embeddable для создания этих таблиц или просто выполняю сопоставление «многие к одному» после создания таблиц.

Answer 1

Это зависит от того, когда вы хотите загрузить данные о стране. Если вы используете встроенный, то данные о стране будут загружены во время загрузки пользовательских данных. Но если вы используете отображение OneToMany с отложенной инициализацией, тогда данные о стране будут загружены, когдавам это нужно.Так что это основано на использовании вами.

Answer 2

Это что-то более личное.Некоторые люди предпочитают использовать Embedded для абстрагирования некоторой информации, а другие более пуристы.

По моему опыту, я предпочитаю отображать объекты очень близко к их представлению в таблицах.Причины просты:

• Техническое обслуживание : легче понять, что происходит на картировании, если какой-то новый разработчик входит в команду, и у него нет большого опыта работы сhibernate.
• Запросы, более похожие на SQL : ваши запросы JPQL / Criteria будут ближе к сгенерированному SQL.Абстракция встроенного может привести к некоторой путанице даже для людей, знакомых с платформой.

И, как уже упоминалось в других ответах, вы всегда будете приводить информацию Country с помощью User, используя встроенный,Это поведение EAGER , чего обычно следует избегать в JPA / Hibernate.

Итак, в вашем случае я бы использовал отношение многие-к-одному.

Answer 3

Зависит от того, как вы будете его использовать.Если вы встраиваете данные страны, они будут находиться в таблице «Пользователь» и будут загружены данными пользователя.

Если в большинстве случаев вам не нужны данные страны каждый раз, когда вы работаете с данными пользователя, вы можете выполнить сопоставление OneToMany.с ленивой инициализацией.В этом случае данные страны будут загружаться только при необходимости со стоимостью дополнительного обращения к БД (которое может быть уменьшено до объединения).