hibernate简单入门教程（四）---------关联映射

这部分内容不建议使用。因为作为一个程序员。表跟表之间的关系不应该简化处理，这样开发中反而会引起更大的麻烦。数据表是一个项目的关系核心所在。

但是我还是把这部分给弄出来。

 

一、常见的映射关系

　一对多：部门对员工。

　多对多：员工可以拥有多个角色然后分配给多个业务权限。

　一对一：学生信息对应家庭信息，成绩信息，档案信息，住宿信息。（通过学生ID主键分化不同情况下调用的业务信息，分离业务便于操作）。

 

二、一对多

　　多对一分两个情况，一个是单向，一个是双向。

　　他们的区别在于从表更新是否会影响到主表。

　　当主表更新时从表必然更新。

　　当从表更新时如果是双向的话主表也会跟着更新，如果是单向的话主表不会受到影响。

　　这里可以节省一些SQL语句的操作。也正因为这些跟新的控制复杂度，所以关联操作老老实实用SQL比较合理。

　　

　　单向一对多配置

　　1）在bean类上增加关联属性比如员工增加部门编号这个属性

　　2）在hbm配置关联标签多的一方如下图

　　　　

<many-to-one name="deptID" column="deptID" class="com.dhh.pojo.dept" not-null="true"></many-to-one>

单向多对一的保存操作：由于保存顺序不同，会产生不同的sql语句，尽量先保存一的一方，再保存多的一方

 

 

　双向一对多配置

 

　　1）在bean类上增加关联属性比如员工增加部门编号这个属性，在部门这边增加set属性

 

　　2）在hbm配置关联标签多的一方如下图，另外一头参考单向配置

　　　　　<!--属性名   　　　　表名  -->
        <set name="Person" table="Person">
            <key>
                <!-- 多的一方的列名 -->
                <column name="deptID"></column>
            </key>
            <one-to-many class="com.dhh.pojo.Person"/>
        </set>

　　3）inverse=“true”这个属性决定了谁交出主动权，注意是交出主动权。决定主从关系。在1-n关系中如果1方为主动方那么更新过程中会增加很多SQL更新语句。

　　　实际上这代表的操作过程中是谁先存储的关系。主动权在部门上时先存部门编号，这样员工编号存入的时候部门编号是正确的。但是如果主动权在员工手上，那么先存入员工编号，再存入部门编号，那么为了维护员工的部门编号字段就会将所有员工编号的部门编号更新一次。无形之中增加了数据库的负荷。

 

　　4cascade="all"属性。这个属性的配置表示哪些操作会影响到级联控制。比如部门编号长期不会更新可以设置更新操作不会产生级联控制效果。

 

三 一对一

　　双向一对多配置

　　1）参考单向一对多配置，然后增加unique=“true”表示是1对1关系

　　2）另一端增加如下标签

　　

                <!--参数名        对方类名       　　　　　　对方类的列名  -->
        <one-to-one name="XXX" class="com.dhh.pojo.XXX" property-ref="XXX"></one-to-one>

 

四 多对多

　1）双方配置Set集合属性

　2）创建中间表

　3）配置文件如下

    <!-- 　　集合名    　　　　中间表名      -->
        <set name="Persons" table="Person_Rule" inverse="true">
            <key>
                <!-- 中间表我方列名  -->
                <column name="r_id"></column>
            </key>
            <!--　　　　　对方类名   　　　　　　　　　 对方在中间列名 -->
            <many-to-many class="com.dhh.pojo.Person" column="p_id"></many-to-many>
        </set>

警告：对于双向 n-n 关联, 须把其中一端的 inverse 设置为 true, 否则可能会造成主键冲突.

 

 

但是项目之间的表关系很多时候都是极为复杂，关联之间非常多，一旦插入hibernate这种看似合理的操作反而会增加决策成本，做事情来十分乱，所以建议不要要