ChatGPT解决这个技术问题 Extra ChatGPT

单向和双向 JPA 和 Hibernate 关联有什么区别?

单向关联和双向关联有什么区别?

由于数据库中生成的表都是相同的,所以我发现的唯一区别是双向关联的每一侧都会有一个引用,而单向则没有。

这是一个单向关联

public class User {
    private int     id;
    private String  name;
    @ManyToOne
    @JoinColumn(
            name = "groupId")
    private Group   group;
}

public class Group {
    private int     id;
    private String  name;
}

双向关联

public class User {
    private int     id;
    private String  name;
    @ManyToOne
    @JoinColumn(
            name = "groupId")
    private Group   group;
}
public class Group {
    private int         id;
    private String      name;
    @OneToMany(mappedBy="group")
    private List<User>  users;
}

区别在于组是否持有用户的引用。

所以我想知道这是否是唯一的区别?推荐哪个?

该组现在将知道它包含哪些用户。我认为这绝不是一个小的差异。
在更新方面,双向关系对我来说变得很混乱。 :)
这可能会有所帮助:thorben-janssen.com/…

P
Perkone

主要区别在于双向关系提供了双向导航访问,因此您无需显式查询即可访问另一侧。它还允许您将级联选项应用于两个方向。

请注意,导航访问并不总是好的,尤其是对于“一对多”和“多对多”的关系。想象一个包含数千个 UserGroup

您将如何访问它们?有这么多用户,您通常需要应用一些过滤和/或分页,因此无论如何您都需要执行查询(除非您使用集合过滤,这对我来说看起来像一个 hack)。在这种情况下,一些开发人员可能倾向于在内存中应用过滤,这显然不利于性能。请注意,拥有这样的关系可以鼓励这种开发人员在不考虑性能影响的情况下使用它。

您将如何将新用户添加到组中?幸运的是,Hibernate 在持久化关系时会查看关系的拥有方,因此您只能设置 User.group。但是,如果要使内存中的对象保持一致,还需要将 User 添加到 Group.users 中。但它会让 Hibernate 从数据库中获取 Group.users 的所有元素!

所以,我不能同意Best Practices 的建议。您需要仔细设计双向关系,考虑用例(您是否需要双向导航访问?)和可能的性能影响。

也可以看看:

阻止 JPA 模型中的“ToMany”关系

Hibernate 映射集合性能问题


嗨,谢谢,您似乎是休眠专家,因为您已经回答了我的问题:stackoverflow.com/questions/5350770/…。现在我不确定关系是否成立,因为我不能在评论中写更多,所以我在这里发布它dpaste.de/J85m。如果可能,请检查一下。:)
@hguser:如果您最终决定建立双向关系,我认为最好从 addUser() 调用 setGroup() 以保持双方一致。
如果我不调用 group.addUser() 中的 setGroup() 怎么样?
@hguser:关系不会持久,请参阅答案中的第 2 点。您可以在没有 addUser() 的情况下调用 setGroup(),但这会导致内存中对象的状态不一致。
我发现我无法正确映射,你能抽出时间在 github 上检查我的项目吗?这是一个小项目。
V
Vlad Mihalcea

有两个主要区别。

访问关联方

第一个与您将如何访问关系有关。对于单向关联,您只能从一端导航关联。

因此,对于单向 @ManyToOne 关联,这意味着您只能从外键所在的子端访问关系。

如果您有单向 @OneToMany 关联,则意味着您只能从管理外键的父端访问关系。

对于双向 @OneToMany 关联,您可以通过两种方式导航关联,无论是从父端还是从子端。

您还需要use add/remove utility methods for bidirectional associations to make sure that both sides are properly synchronized

表现

第二个方面与性能有关。

对于@OneToMany,单向关联的性能不如双向关联。对于@OneToOne,如果 Hibernate 无法判断是否应该分配 Proxy 或 null 值,则双向关联将导致急切地获取父级。对于@ManyToMany,集合类型有很大的不同,因为集合比列表表现更好。


但据我所知,父方始终是拥有外键的一方。这两句话在我看来是矛盾的。 from the child side where the foreign key resides. from the parent side where the foreign key resides.
FK 总是站在孩子一边。单向 OneToMany 管理可以在连接表中的子表中的 FK。点击链接了解更多详情。
你好@Vlad 一个问题:多对多关联可以是单向的吗?我是说性能。 @ManyToMany @JoinTable(name = "role_privileges", joinColumns = { @JoinColumn(name = "role_id", referencedColumnName = "id") }, inverseJoinColumns = { @JoinColumn(name = "privilege_id", referencedColumnName = "id") }) private Set<Privilege> privileges=new HashSet<Privilege>();
对于多对多,从性能的角度来看,它们是单向的还是双向的并不重要。
k
kvista

我不是 100% 确定这是唯一的区别,但这是主要区别。 Hibernate 文档还建议进行双向关联:

http://docs.jboss.org/hibernate/core/3.3/reference/en/html/best-practices.html

具体来说:

首选双向关联:单向关联更难查询。在大型应用程序中,几乎所有关联都必须在查询中双向导航。

我个人对这个一揽子建议有一个小问题——在我看来,在某些情况下,孩子没有任何实际理由了解其父母(例如,为什么订单项目需要知道它的订单相关联?),但我确实在合理的时间内看到了它的价值。而且由于双向性并没有真正伤害任何东西,我不觉得坚持它太令人反感。


正如 axtavt 所解释的,在某些情况下,双向性可能会受到伤害!我会非常小心映射到 Hibernate 实体中的每个关系!除非您确切地知道自己在做什么,否则您最终可能会在 Hibernate 中加载所需的无穷无尽的时间。仔细考虑用例,为不同的用例使用不同的模型类。前任在事物列表中,我不需要所有相关对象,只需要标签和 ID。因此,对我来说,列表实体与详细实体不同(而且非常简单)。
C
Constantino Cronemberger

在编码方面,双向关系实现起来更复杂,因为应用程序负责根据 JPA 规范 5(第 42 页)使双方保持同步。不幸的是,规范中给出的例子没有给出更多细节,所以它没有给出复杂程度的概念。

当不使用二级缓存时,没有正确实现关系方法通常不是问题,因为实例在事务结束时被丢弃。

当使用二级缓存时,如果由于错误实现的关系处理方法而损坏了任何东西,这意味着其他事务也会看到损坏的元素(二级缓存是全局的)。

正确实现的双向关系可以使查询和代码更简单,但如果它在业务逻辑方面没有真正意义,则不应使用。