共计 855 个字符,预计需要花费 3 分钟才能阅读完成。
背景
目前很多公司都不思考退出外键了,很多人工作中也不怎么应用外键了,毕竟每次做 DELETE 或者 UPDATE 都必须思考外键束缚,会导致开发的时候很苦楚, 测试数据极为不不便。
在笔者看来,在相应的场景下,如果应用的一个性能弊大于利,可能就不会抉择了。所以是否应用外键取决相应的场景,也不可去齐全摈弃外键。
为什么会很少应用外键呢?
目前应用外键的确存在一些不便,这也是大多数人不应用的起因所在。我具体总结了会存在这么几个起因:
1、减少数据库压力
外键等于把数据的一致性事务实现,全副交给数据库服务器实现,并且有了外键,当做一些波及外键字段的增、删、更新操作之后,须要触发相干操作去查看,而不得不耗费资源。
2、死锁问题
若是高并发大流量事务场景,应用外键还可能容易造成死锁。
3、开发不不便
有外键时,无论开发还是保护,须要手工保护数据时,都不太不便,要思考级联因素。
4、数据刷库
理论开发过程中,免不了要常常刷库,导入或删除数据,外键的存在会让表删除或插入失败(表数据变更有程序要求)。
5、外键保护
随着我的项目的迭代,表之间的关系也会发生变化,比方有个外键须要删除;或是要新增一个外键,但因为现有数据不准,导致外键加不下来,长此以往,ER 图也不能残缺的显示表关系,这 ER 图看还是不看?
外键真的就没有用了吗?
存在即正当,每一个产品,每一个性能既然存在,在某些中央也是存在劣势的。笔者总结了一下外键的几个劣势点:
1、数据库的一致性
由数据库本身保证数据一致性、完整性会更牢靠,程序很难 100%保证数据的一致性、完整性,而用外键即便在数据库服务器当机或者呈现其余问题的时候,也可能最大限度的保证数据的一致性和完整性。
2、ER 图可靠性
有主外键的数据库设计能够减少 ER 图的可读性(也有特地的公司产品特地重视的这一方面)。
总结
1、如是单机且低并发,也不须要性能调优,再或者不能用程序保证数据的一致性,完整性,能够应用外键,如学校的,保证数据的一致性与残缺,基数也不大。
2、如果为了高并发,分布式,使零碎性能更优,以及更好保护,则不要去应用外键。