您的位置:首页 > 数据库 > 数据库管理 > 正文

数据库该不该用外键

更多 时间:2015-1-6 类别:数据库 浏览量:664

数据库该不该用外键

数据库该不该用外键

一、认为使用外键的原因

 

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的时候都要通过这个约束来验证数据是否完整一致。这个时候性能上的缺失可能是几小时甚至是几十个小时。

 

 

标签:外键