双向JPA OneToMany / ManyToOne关联中的“关联的反面”是什么？

一尘不染

双向JPA OneToMany / ManyToOne关联中的“关联的反面”是什么？

hibernate

在@OneToManyJPA注释参考的示例部分中：

示例1-59 @OneToMany-具有泛型的客户类

@Entity
public class Customer implements Serializable {
    ...
    @OneToMany(cascade=ALL, mappedBy="customer")
    public Set<Order> getOrders() { 
        return orders; 
    }
    ...
}

示例1-60 @ManyToOne-具有泛型的Order类

@Entity
public class Order implements Serializable {
    ...
    @ManyToOne
    @JoinColumn(name="CUST_ID", nullable=false)
    public Customer getCustomer() { 
        return customer; 
    }
    ...
}

在我看来，Customer实体是协会的所有者。但是，在mappedBy同一文档中对属性的说明中写道：

如果关系是双向的，则将关联的反（非所有权）侧的maptedBy元素设置为拥有该关系的字段或属性的名称，如示例1-60所示。

但是，如果我没有记错，则在示例中看起来，mappedBy实际上是在关联的拥有方而不是非拥有方指定了。

所以我的问题基本上是：

在双向（一对多/多对一）关联中，所有者是哪个实体？我们如何指定一方为所有者？我们如何指定多方为所有者？
“关联的反面”是什么意思？我们如何将一侧指定为逆？我们如何将“多面”指定为反面？

阅读 428

2020-06-20

共1个答案

一尘不染

要了解这一点，您必须退后一步。在OO中，客户拥有订单（订单是客户对象中的列表）。没有客户就无法下订单。因此，客户似乎是订单的所有者。

但是在SQL世界中，一项实际上将包含指向另一项的指针。由于N个订单有1个客户，因此每个订单都包含指向其所属客户的外键。这是“连接”，这意味着顺序“拥有”（或字面上包含）连接（信息）。这与OO
/模型世界完全相反。

这可能有助于了解：

public class Customer {
     // This field doesn't exist in the database
     // It is simulated with a SQL query
     // "OO speak": Customer owns the orders
     private List<Order> orders;
}

public class Order {
     // This field actually exists in the DB
     // In a purely OO model, we could omit it
     // "DB speak": Order contains a foreign key to customer
     private Customer customer;
}

反面是对象的OO“所有者”，在这种情况下是客户。客户在表中没有存储订单的列，因此您必须告诉它可以在订单表中的何处保存该数据（通过发生mappedBy）。

另一个常见的示例是带有节点的树，这些节点可以是父母也可以是孩子。在这种情况下，两个字段在一个类中使用：

public class Node {
    // Again, this is managed by Hibernate.
    // There is no matching column in the database.
    @OneToMany(cascade = CascadeType.ALL) // mappedBy is only necessary when there are two fields with the type "Node"
    private List<Node> children;

    // This field exists in the database.
    // For the OO model, it's not really necessary and in fact
    // some XML implementations omit it to save memory.
    // Of course, that limits your options to navigate the tree.
    @ManyToOne
    private Node parent;
}

这解释了“外键”多对一设计的工作。第二种方法是使用另一个表来维护关系。这意味着，对于我们的第一个示例，您有三个表：一个有客户的表，一个有订单的表和一个带有两对主键（customerPK，orderPK）的两列表。

这种方法比上面的方法更灵活（它可以轻松处理一对一，多对一，一对多甚至多对多）。价格是

有点慢（必须维护另一个表，并且联接使用三个表而不是两个表），
join语法更复杂（如果您必须手动编写许多查询，例如当您尝试调试某些内容时，这可能很繁琐）
它更容易出错，因为当管理连接表的代码出现问题时，您突然会得到太多或太少的结果。

这就是为什么我很少推荐这种方法的原因。

2020-06-20