Hibernate关联关系映射 一对一 一对多 多对一

单向关联(Unidirectional associations)

7.2.1. 多对一(many to one)

单向many-to-one关联是最常见的单向关联关系。

 

 一对一(one to one)

基于外键关联的单向一对一关联单向多对一关联几乎是一样的。唯一的不同就是单向一对一关联中的外键字段具有唯一性约束。

基于主键关联的单向一对一关联通常使用一个特定的id生成器。(请注意,在这个例子中我们掉换了关联的方向。)

 一对多(one to many)

基于外键关联的单向一对多关联是一种很少见的情况,并不推荐使用。

我们认为对于这种关联关系最好使用连接表。

 

 

 

7.3. 使用连接表的单向关联(Unidirectional associations with join tables)


7.3.1. 一对多(one to many)
基于连接表的单向一对多关联 应该优先被采用。请注意,通过指定unique="true",我们可以把多样性从多对多改变为一对多。

7.3.2. 多对一(many to one)
基于连接表的单向多对一关联在关联关系可选的情况下应用也很普遍。


7.3.3. 一对一(one to one)
基于连接表的单向一对一关联非常少见,但也是可行的。

7.3.4. 多对多(many to many)
最后,还有 单向多对多关联.

 

 

7.4. 双向关联(Bidirectional associations)
7.4.1. 一对多(one to many) / 多对一(many to one)
双向多对一关联 是最常见的关联关系。(这也是标准的父/子关联关系。)

如果你使用List(或者其他有序集合类),你需要设置外键对应的key列为 not null,让Hibernate来从集合端管理关联,维护每个元素的索引(通过设置update="false" and insert="false"来对另一端反向操作)。

假若集合映射的<key>元素对应的底层外键字段是NOT NULL的,那么为这一key元素定义not-null="true"是很重要的。不要仅仅为可能的嵌套<column>元素定义not-null="true",<key>元素也是需要的。

 

7.4.2. 一对一(one to one)
基于外键关联的双向一对一关联也很常见。

基于主键关联的一对一关联需要使用特定的id生成器。

 

 

7.5. 使用连接表的双向关联(Bidirectional associations with join tables)
7.5.1. 一对多(one to many) /多对一( many to one)
基于连接表的双向一对多关联。注意inverse="true"可以出现在关联的任意一端,即collection端或者join端。

7.5.2. 一对一(one to one)
基于连接表的双向一对一关联极为罕见,但也是可行的。

 

7.5.3. 多对多(many to many)
最后,还有 双向多对多关联.

 

 

7.6. 更复杂的关联映射

更复杂的关联连接极为罕见。 通过在映射文档中嵌入SQL片断,Hibernate也可以处理更为复杂的情况。比如,假若包含历史帐户数据的表定义了accountNumber, effectiveEndDateeffectiveStartDate字段,按照下面映射:

 

那么我们可以对目前(current)实例(其effectiveEndDate为null)使用这样的关联映射:

更复杂的例子,假想Employee和Organization之间的关联是通过一个Employment中间表维护的,而中间表中填充了很多历史雇员数据。那“雇员的最新雇主”这个关联(最新雇主就是startDate最后的那个)可以这样映射:

使用这一功能时可以充满创意,但通常更加实用的是用HQL或条件查询来处理这些情形。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值