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