数据库该不该用外键

数据库该不该用外键

一、认为使用外键的原因

1.通过外键，数据库自身能够保证数据的完整性与一致性，虽然我们在程序中也能够写些代码来维护，但是程序始终没有办法100%的保证数据的完整性与一致性。而外键本身属于数据库的一部分，所以在数据库服务器出现问题的时候，它也能最大限度的保存数据库的完整性与一致性。

2.有外键的数据库可以使ER图更具有可读性，数据库中表与表之间的关系更加一目了然，这对于系统的二次开发或是维护也是相当有用的。

3.在业务逻辑上，通过外键可以更加直观的理解业务逻辑，在设计功能时起到了辅助作用，让设计更加周到完善。

4.对于一个项目，开发人员总是不断变动的，开发人员的能力也是层次不齐的，那么通过代码来保证数据完整性更是难上加难的事情，有了外键在一定程度上约束了开发人员，能够避免一些低级错误而导致数据的不完整。

5、避免数据冗余

不使用外键，会导致数据冗余，在级联最底层的表可能会重复好几层的数据 必然导致最底层的表数据量翻倍，IO瓶颈是数据库性能瓶颈之一。

二、认为不需要使用外键的原因

1、程序逻辑

某些程序逻辑中，程序的逻辑已经足够保证完整性，我会在存储过程或包等地方做严谨的判断

2、性能问题

这是很多人不喜欢用的关键原因，比如一个业务流水表，频繁插入数据，如果这个表身上有3外键，那么每次插入一条，就必须对这3个外键对应的3个表做相应的查找判断有无对应数据，如果这3个表也很大，那就这3个表的判断时间就很常，虽然外键指向的关联表的字段肯定是索引，但是我觉得很多时候，这样的判断本来就在程序里控制好了，通过外键再判断一次，就是降低性能；而且其实有的地方判不判断也无所谓的，但是用了外键，就必须化时间去判断，无论数据库内部多么优化外键对于数据的检索速度，它总是一个不小的消耗

3、维护麻烦

很多公司的软件都是定制的，这种定制的东西，随意性相对较大，项目开发实施过程中，需要经常对表修修补补；还有就是业务逻辑有bug或者其他情况，需要经常手工维护数据，有错综复杂的外键关联着，很是麻烦

三、我们要从以下几个方面来分析该不该上外键约束

1、项目业务逻辑的复杂度

业务逻辑其实是一个项目最根本的东西，是项目的一个核型，它就像一条主线，贯穿于项目的始末。所以当业务逻辑非常复杂的时候，有很多都存在关联。这个时候外键恰恰帮我们理清了他们之间的关系，同时在项目中使用外键更容易保证数据的完整性与一致性。由于关系的复杂，我们已经没有办法使用程序来100%保证数据的完整性与一致性了。相反，如果业务逻辑不复杂，关系很明了，那么我们在程序里就可以保证完整性与一致性了，当然也没有必要用外键的了。

2、项目计划进行的时间

程序员的流动性是很大的，也许一个项目开发到一半的时候，整个项目组除了项目经理外程序员都全部换人了，如果文档没有及时跟上，或是交接的时候不明确，那对于项目来说是很危险的。对于那些半路杀进来的程序员，虽然有经验的程序员会在编码的时候思考完整性的问题，但是由于各种原因，他们没有办法100%的通过程序保证数据的完整性与一致性。有经验的尚且如此，所以这个时候外键就为项目的完整性把好了最后一道关卡，无论他们对项目是否熟悉，在完整性与一致性的问题上面，数据库自身已经做好了充分的准备。相反，项目如果周期很短，人员变动也很小，那就可以撇开这个因素，从其他方面考虑是否需要使用外键。

3、安全性与完整性

这个问题其实最好理解，如果项目对数据有着非常苛刻的安全性、完整性与一致性的要求，那必然要用外键，可能会缺失一部分性能，即使是这样也是值得的，这样从最大程度上满足了项目的需求，这才是关键。

4、性能

上面第三点已经讨论的性能的问题了。对于大型的系统，如果每天有百万级的数据操作，这个时候如果使用外键，那性能就变成了致命的问题。外键就是一种约束，我们每操作一次insert、update或是delete的时候都要通过这个约束来验证数据是否完整一致。这个时候性能上的缺失可能是几小时甚至是几十个小时。