现在有一个学生表student和一个课程表course,他们的关系是一对多;现在有两种方式写法
1、在课程表的PO类中添加Student类的对象引用。
Public Class Course{
      ……
      private Student stu;
      ……
}
  在hbm映射文件中写
<many-to-one name="stu" class="....." column="...." not-null="true"></many-to-one>2、第二种方法是在PO类中添加Student外键的引用。
Public Class Course{
      ……
      private String stuId;
      ……
}
  在hbm文件中写
 <property name="stu" type="java.lang.String">
            <column name="...." length="50" />
        </property>
然后再在数据库中添加外键的引用约束。(或者不做这一步,在其他层中对插入的数据进行验证)这两种方法哪种好?特别是对于高并发量的应用系统。

解决方案 »

  1.   


    我知道第一种方法已经生成外键了,但是在Course类中用Student的引用是不是必要?第二种方法一样可以做到,他们之间有什么优缺点吗?PS:如2楼所说,就算存在着关联关系,我在数据库中不使用外键可以不?我在其他层中,保证数据的完整性,这样可以不?
      

  2.   


    但是第一种方法,Hibernate已经帮你生成外键约束了啊
      

  3.   

    不要用hibernate反向生成就不会在实际的数据库中出现外键约束。手工建表!一般配置时大多采用第一种。 直接在多的一端中配置一的对象,这样做一般是出于在拿到多的时候还想得到一,(hibernate自动帮助你获取关联对象);如果采用第二种方式,那么还得在根据FK在查询一次(需要手工查询)。当然这个要看你的业务有没有这样的需求了。
    第二种所谓的外键引用也就是不用hibernate来管理关联关系,只是把外键当做表的一个普通字段来处理。这样在要获取关联对象时,必须重新写查询语句。这个时候其实算是废弃hibernate的优势,而改为只是做普通的PO映射了。
      

  4.   

    同意楼上的,我从来不用hibernate生成数据表,都是自己手动添加的。对于表之间的关系,我想应该尽量减少他们之间的外键约束。
      

  5.   


    我同意你的说法,第二种方法是废弃的Hibernate的优势,现在公司的项目所有的PO类都是使用第二种方法,
    让我感觉有点怪,Hibernate本来就是提供面向对象的方法来实现对数据的存取,现在这样写,无疑是要对所有的数据表结构都要了解,这样做有好处吗???
      

  6.   

    这个的具体看下你们的项目了,如果只是单纯的记录外键信息,那么这样做无可厚非,可能是因为你们的头考虑到业务需求中对表的操作很少涉及到联动获取。
    个人觉得针对第二种情况的具体应用要看业务对该表的操作及前端数据的展示。因为有时候使用hibernate的关联很大程度上是为了在前端展示时的方便(利用延迟)。如果页面不涉及关联数据的显示和处理,那么完全可以使用单纯将外键当做字段进行处理。因此在做这些配置时,间或的要考虑最终前端数据的展示及处理。