使用ORM框架时，用外键好还是不用外键好呢？

这几个月，我都在用JPA做练习，除非就几个表，我才用JDBC直接访问。使用映射框架能够节省很多代码量，首先那些烦人的数据库表的字段再也不用一个个的写了。确实是映射框架能极大的提高开发效率，这在自己的实践中也证实了。不过前提是IDE的代码生成，如果没有IDE的代码生成，那也是比较麻烦的。

        在使用的过程中，自己都是建好外键，尤其，我写一个OA时，使用了powerdesigner设计了下数据库，然后建立外键，然后生成SQL语句，最后导入数据库，接着借助IDE生成实体类。

        第一 那些外键就会以多对一的形式体现出来，此时一方引用着唯一的另一方，而另一方表现为一个集合的方式引用前者，但是很多时候，我查询的数据都是带很多条件的，它这个一对多引用的集合，很多情况下，并不会用。当然默认情况下它是延迟加载的，也就是直到访问时才去真正从数据库里查询。

        反过来，如果不使用外键的话，自己去设置自己需要的集合就可以了，此时通过一定的数据库访问方法获得，并设置其值。

       第二，在页面中，如果显示数据，借助外键，只需查询一个对象就可以了 就是用find方法，然后集合可以直接在页面用JSTL获得。但是有时候更新时，往往不同步，于是更新完后必须flush下，才行。

      反过来，不使用外键，就不会涉及数据同步问题了，因为实体间关系靠程序自己分辨，而不用映射框架去映射。

      第三，使用外键时，如果一个实体的集合字段的某个需要更新或删除时，尤其大量的操作这个实体的List时，List变了，提交后，自动同步到数据库，处理时能节省好多代码。

      反过来，不使用外键，可就真需要自己去维护这些从属关系了，当然了也不是很麻烦。

      第四，使用外键时，那些外键就以对象形式体现了，被引用主键的那个实体，必须查询出来后，才能set进入当前的实体，因此要多出好多查询，虽然，很多时候可以从缓存中拿到，而不是去数据库里现取，但总感觉很占用内存。

      反过来，不使用外键，有ID字段的int值就可以set了，而不用查询出那个对象。

其实拿id构造一个对象也是可以的，因为这个时候真正需要的其实就是这个对象的ID字段，netbeans在生成实体类时都肯定有个带主键的构造器。从另一方面讲，之所以查询一下，可以确认该对象还存在否，如果不存在，可以确认目前合理不合理。

最后，JPA在初始化时cpu会100%几秒，只要修改了类文件后，涉及到访问数据库的操作，就会发生。感觉sun出品的框架都很重量级，尤其EJB更是如此。不过JPA真的很方便快捷。当然了这应该算作是hibernate的功劳，是hibernate引领了如此美妙的ORM。

综上考虑，我下一步也不使用外键了，这样不用考虑什么多对多、多对一关系，好像更像封装的JDBC了，呵呵！

不知道效果如何，前几天下了JSPRun的一个论坛项目，它里面就是没用外键，hibernate的映射配置文件非常简洁，就是和数据库的直接映射，然后具体的逻辑关系全在代码中自己维护！

       今天写到这，明天开始体验！