什么时候适合使用双向关联，什么时候不适合？答案

【问题标题】：When is it appropriate to use a bidirectional association and when is it not?什么时候适合使用双向关联，什么时候不适合？
【发布时间】：2011-09-13 17:14:57
【问题描述】：

假设我们要构建一个类似 eBay 的应用程序，其中我们有一个名为 Customer 的实体和一个名为 Order 的实体。

从关系的角度来看，我将其建模为：

Customer
+----+-----+
| ID | ... |
+----+-----+

Order
+----+-------------+-----+
| ID | CUSTOMER_ID | ... |
+----+-------------+-----+

现在当我想将它映射到 JPA 时，我有多种选择：

创建从订单到客户的单向多对一关联。恕我直言，这是最接近关系模型的。不利的一面是，为了找到给定客户的所有订单，我必须编写一个 JPQL 查询，因为客户对其订单一无所知。此外，我不能以 OO 自然的方式为客户添加新订单（例如customer.addOrder(aNewOrder);）。
创建从客户到订单的一对多关联。这样，为了找到给定客户的所有订单，我可以使用customer.getOders()，并且可以以 OO 自然的方式为客户添加新订单。缺点是为了找出下给定订单的客户，我应该使用 JPQL。
创建从客户到订单的双向一对多关联。这样，我不需要编写任何 JPQL 查询来检索客户的所有订单或已下给定订单的客户。缺点是增加了维护双向关联的复杂性。

因此，我没有看到关于是否必须使用单向关联或双向关联是否“正确”的明确论据。换句话说，在我看来，这一切都归结为模型设计者/实施者的个人偏好和品味。

我是对的还是有规则可以根据这些规则确定给定关联的正确方向？

【问题讨论】：

显然，当您需要从双方访问时，您会使用双向关系。持久性解决方案根本不应该出现在该选择中。
@DataNucleus：但无论关联是否是双向的，最终都可以找出客户或下订单的客户的订单。
当然，但我的意思是你设计你的模型以适应它在你的应用程序中的使用方式，而不是适应持久层。是的，无论是否为 bidir，始终可以为客户或客户获取订单 - 您选择根据性能等获取该信息的机制。
好的，那么我根据您和 Alex 的说法得出结论，基本上我们可以选择任何选项，但根据我们的使用模式和性能要求，我们可能会决定选择一个而不是其他选项。换句话说，似乎没有明确的规则或通常“正确”的选择。

标签： hibernate orm jpa entity-relationship

【解决方案1】：

很大程度上取决于您预期的每位客户的订单数量。如果您期望每个客户有很多订单（想想 eBay），那么让客户拥有与其相关的所有订单将不是很有效（或者需要一些努力来维持懒惰的关联）。在这种情况下，我推荐方法#1。写一些查询没有错。

但是，如果您希望大多数客户的订单很少，那么双向方法 #3 就可以了。

我认为 #2 没有多大价值，因为订单始终与一位客户相关联。

【讨论】：