请给我讲讲在hibernate中，啥时候用“一对多”、“多对一”、“一对一”、“多对多”？

Posted 2023-03-15

我主要是分不清区分它们的方法，请大家详细讲讲怎么区分，最好举几个例子。这个问题我会加到200分的，如果答案满意我最后还会追加50分。

■■■■■■■■■■■■■■■■■■■
请不要从其它地方复制粘贴
■■■■■■■■■■■■■■■■■■■

.

一对一就是比如每个人都有且只有一张身份证（排除你的身份证是假冒伪劣啥的），然后必然有且只有一个一个户口本，所以身份证和户口是一对一的关系，你一次查询就可以把一个人的身份证和户口都查询出来，但是由于用途的关系，身份证和户口还是需要用两张表格来存储的。
一对多的情况就是比如一个公司有许多的职员，于是公司和职员的关系就是一对多的，用hibernate，职员就是公司的一个set字段，比如
Class company
private string companyName;
private set Employees;
...
你一次查询公司Company company=hibernatedao.queryCompany(id);
然后可以company.getEmployees()得到他的所有雇员，这就是一对多的好处

多对多举个例子就是订单和商品的关系，一张订单可以有许多商品，一个商品可以从属多个订单，所以他们之间是双向关联的关系，各自的类都有对方的集合（set）,好处和一对多差不多，不过多对多一般要有一张中间表来存储他们之间的关联关系，比如 订单1---牙刷 订单1---毛巾 订单2---牙刷，其实多对多是比较复杂的，推荐能不用多对多尽量不用
我讲的都是概念上的东西，如果要研究代码，楼主最好去找hibernate1对1，1对多的demo学着做，这样对自己也提高的比较快 参考技术A 1.什么时候用？
这个取决于需求，比如，你的师生管理项目中，客户已经明确规定，在这个项目中，老师可以教多个学生，学生也可以有多个老师，这很明显是m：n就是多对多的关系。如果说做部门与员工这样的表，那么一个部门可以有多个员工，但是，每个员工只能在一个部门工作，这就是一个1：M一对多的关系。到底要用哪种关系，取决于你对客户需求的理解
2.怎么用？
楼主已经表明不要用拷贝，所以推荐楼主去www.hibernate.org看看文档，其中有关系映射这部分，包括了，很多方面的关联，单、双向关联、带第三张表的单双向关联，不再赘述。本回答被提问者采纳 参考技术B 一对多:一个购物车可以放多个商品
多对一:多个商品可以放一个购物车
一对一:一个客户可以有一个购物车
多对多:多个客户对应多个商品
hibernate的配置不是很麻烦,基本上你设定好了数据库的表结构,用eclipse自动生成配置文件就可以了,在取值的时候如果是一对多
a.getBs();就获得了多的对象,同样,如果是多对一:b.getA();就获得了A对象.
多对多在实际中不存在.一对一就是普通的表关联.意义不大. 参考技术C 1。一对多
表1 用户表 表2 信息表
表1 结构 id userName
表2 结构 id userId content
数据 表1 id userName
1 大毛
表2 id userId content
1 1 你好
2 1 你好哇
看下数据就能发现关系
这样的关系就是一(表1中的ID)对多(表2中的userId)
2。多对一 个人感觉和上面一样
假如你在表一中设置的关系是一对多 那么在表2中关系就是多对一
3。一对一
你可以理解为一个对应一个 这个不做多余的解释
4。多对多
在处理用户和角色时常常被用到
一个用户可以有多个角色 一个角色又可以被多个用户使用
这样的关系就是多对多

以上都是按我自己的理解说的
然后有些小的方法和大家分享下
Hibernate实际上可以做到 这样的关联 但这并不是唯一的办法
结合我个人做的实际项目 还可以有办法
运用数据库的主 外键关联 关系复杂可以做中间的影射表(多对多关系)

都给你发了 你看不到？ 参考技术D 一个老师教一个班的学生 这个就是一对多
一个学生只能有一个学号 这个就是一对一
同一门课可以有很多老师来教，来教这门课的老师同时也可以交很多门课 这个就是多对多

至于多对一 只是一对一的特殊情况
N个学生组成一个班级 那么学生就是多的一端 班级就是一的那端

建议去看看夏析写的《深入浅出Hibernate》·对你很有帮助~

可嵌入与一对多

【中文标题】可嵌入与一对多

【英文标题】：Embeddable vs one to many

【发布时间】：2017-10-16 11:37:16

【问题描述】：

我在 Dzone 中看到一篇关于 Post 和 Post Details（两个不同的实体）以及它们之间的关系的文章。那里的帖子及其详细信息在不同的表格中。但正如我所见，帖子详细信息是一个可嵌入的部分，因为没有“父”帖子就无法使用它。那么在另一个表中分隔它的逻辑是什么？

请给我一个更清楚的解释什么时候使用哪个？

【问题讨论】：

你能在这里提供更多的上下文吗？事实上，可能不需要两张表，但做出这个决定可能是有正当理由的，这显示一些数据可能会解释。

请添加帖子链接

在数据是一点信息的情况下，将结构化数据与其父行一起存储可能是一个不错的概念。在this link，我回答了我什么时候应该按原样保存JSON？这个问题并不完全相同，但非常相关。可能很有趣……

【参考方案1】：

可嵌入类表示其父类的状态。因此，以您为例，*** POST 具有一个不变的 ID，并用于不可破坏的 URL 以进行共享，例如http://***.com/q/44017535/146325。还有一系列其他属性（状态、投票等）是标量属性。当帖子被编辑时，我们有各种版本的文本（保留并可供有足够代表的人看到）。这些是您的帖子详细信息。

“在另一个表中分隔它的逻辑是什么？”

因为在不同的表中保存不同的东西是关系数据库所做的。表示此数据模型的标准方式是父表 POST 和子表 POST_DETAIL 具有通过外键强制执行的定义关系。

可嵌入是来自面向对象编程的概念。 Oracle 确实支持数据库中的对象关系结构。因此可以定义一个 POST_DETAIL 类型并创建一个 POST 表，该表的列声明为该类型的嵌套表。但是，这将是一个糟糕的设计，原因有两个：

用于处理嵌套表的 SQL 很笨拙。例如，要获取 POST 及其文本的最新版本，每次我们需要显示它时都需要取消嵌套详细信息的集合。在计算上与加入子表和过滤最新版本标志没有太大区别，但更难优化。 孩子可以自己生孩子。在帖子的情况下，标签是详细信息，因为它们可能会因编辑而有所不同。但是，如果您在 POST_DETAIL 中嵌入 TAG 嵌入在 POST 中，那么找到所有带有 [oracle] 标签的帖子有多容易？

这是面向对象设计和关系设计之间的区别。

OO 具有很强的层次性：一切都属于某物，获取细节的方式是通过父级。这种方法在处理事物的单个实例时效果很好，因此适用于 UI 设计。

关系优先考虑共性：同一类型的所有事物都通过与其他事物的链接组合在一起。这种方法适用于处理多组事物，因此适用于数据管理任务（您想查找所有在柏林工作或工作是工程师或由 ELLIOTT 管理的员工吗？）

“给我一个更清楚的解释什么时候使用哪个”

始终将数据以相关方式存储在单独的表中。在有意义的情况下使用 OO 模式构建 API。

【讨论】：

只是一个迂腐的小问题。 “关系”实际上并不优先考虑关系。 FK 关系是一个笨拙的工作回合。 RDBMS 中的“关系”指的是特定表中的所有行都是相关的，因为它们是同一类型的事物，而不是它们与其他表中的其他行相关。除此之外 - 很好的答案。

@BriteSponge - 感谢您的反馈。我急于完成这篇文章，但没有正确阅读。