在我看来hibernate最麻烦的一件事就是配置外键关联，稍微不慎就会出现配置错误的情况，现在的项目全部都是在使用mybaits，而mybaits使用就简单的多，起码虽然说是要自己写mysql语句，但是起码这种做法在现阶段的项目开发中还是非常的流行，以前经常听到眼言论说用hibernate开发会比mybaits要来得快，其实那应该 是对于高手而言，但是绝大部分如我这群菜逼而言，老老实实的写sql语句会更好一点，废话不多说，今天主要是谈谈外键关联对在项目开发中的影响。
表的关联，在某种程度上来说只是一种逻辑概念，比如在我们开始项目之初，是需要进行表设计，在用diagram designe这类工具r设计表的时候，难免不会有各重业务上的逻辑关联的，这个时候如果你不使用外键管理，是很容易造成自身的逻辑混乱的，如果有那么一根根线连着，我们就能追根溯本，搞清整个项目的流程结构。
但是在物理结构的表上面，我们没必要进行物理上的硬绑定，而我们期望的关联，其实只是数据上存在的联系，而这种联系更多的是存在我们脑海里，而非明面上，所以在进行业务代码实现的时候，我们编写程序的时候，只需要在程序中实现逻辑关连 的存取即可，但是如果我们非得加上什么外键关联这层关系，只会带来更多的资源消耗来进行所谓的一致性检验，数据完整性检验，其实有些时候我们并不需要这层检验和约束。
我抽空问了几个其他公司的朋友，在mysql的时候，很多地方都直接把外键跟直接删除，当然这些都是互联网公司，因为相对于业务逻辑和速度，数据的完整性显得并不那么重要，各种的锁表估计也是追求性能的我们所不能接受的，若是遇到各种高并发和大流量的情况，外键造成的死锁和事务回滚那直接只会让程序猿骂娘。
当然在比如说银行或者是各种erp系统里面，数据完整性比企业的命还重要的时候，通过程序去控制各种业务逻辑显得并不那么可靠，因为程序总是那么容易攻破，而数据库稍微要更难一点点，而且在银行这种企业里面，数据是绝不能够轻易删除，而非向我们这样，如果哪些数据不尽人意，直接物理层面的给删除掉。
总之，外键的优点就是保证数据的完整性，缺点太多，不再累述。
)
)
