要了解这一点,您必须退后一步。在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语法更复杂(如果您必须手动编写许多查询,例如当您尝试调试某些内容时,这可能很繁琐)
- 它更容易出错,因为当管理连接表的代码出现问题时,您突然会得到太多或太少的结果。
这就是为什么我很少推荐这种方法的原因。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)