数据库设计中一个矛盾:数据库外键,用还是不用

最近在做一个派单系统数据库设计，在设计中有些疑惑的地方中午在网上发起一个话题讨论.
我把这个讨论流程.发过来 大家可以可以看看.

也可以发表一下自己的意见.

对于主/外键/索引来说，在一些开发团队中被认为是处理数据库关系的利器，也被某些开发团队认为是处理某些具体业务的魔鬼，您的观点呢？在实际应用中您会采取哪种方式？

大家共同观点：

主键和索引是不可少的，不仅可以优化数据检索速度，开发人员还省不其它的工作,

矛盾焦点：数据库设计是否需要外键。这里有两个问题：一个是如何保证数据库数据的完整性和一致性；二是第一条对性能的影响

2009-11-11 13:07 changShaHacker

正方观点：

1，由数据库自身保证数据一致性，完整性，更可靠，因为程序很难100％保证数据的完整性，而用外键即使在数据库服务器当机或者出现其他问题的时候，也能够最大限度的保证数据的一致性和完整性。

eg：数据库和应用是一对多的关系，Ａ应用会维护他那部分数据的完整性，系统一变大时，增加了Ｂ应用，Ａ和Ｂ两个应用也许是不同的开发团队来做的。他们如何协调保证数据的完整性，而且一年以后如果又增加了C应用呢？

2，有主外键的数据库设计可以增加ER图的可读性，这点在数据库设计时非常重要。

3，外键在一定程度上说明的业务逻辑，会使设计周到具体全面

2009-11-11 13:08 TeDongDesiger

反方观点：

1，可以用触发器或应用程序保证数据的完整性

2，过分强调或者说使用主键／外键会平添开发难度，导致表过多等问题

3，不用外键时数据管理简单，操作方便，性能高（导入导出等操作，在insert, update, delete 数据的时候更快）

eg:在海量的数据库中想都不要去想外键，试想，一个程序每天要insert数百万条记录，当存在外键约束的时候，每次要去扫描此记录是否合格，一般还不止一个字段有外键，这样扫描的数量是成级数的增长！我的一个程序入库在3个小时做完，如果加上外键，需要28个小时！

结论：

1，在大型系统中（性能要求不高，安全要求高），使用外键；在大型系统中（性能要求高，安全自己控制），不用外键；小系统随便，最好用外键。

2，用外键要适当，不能过分追求

3，不用外键而用程序控制数据一致性和完整性时，应该写一层来保证，然后个个应用通过这个层来访问数据库

在另一个社区IT-智库中讨论结果:

我先起个引子。

毫无疑问很多人都会对外键维护的复杂进行妥协，对它的性能产生怀疑，但在下一直固执的认为，外键就是系统完成性的一部分，不但要使用，而且要在符合语义环境的前提下尽量多的使用。

---------回复--------------

其实不然，完整性固然重要，但效率也非常重要，势必要在利用外键约束完整性与效率等因素之间寻求一个平衡点。

---------回复--------------

外键约束可以保障性能的完整性，而其他的业务逻辑也可以从一定程度上完成类似的功能；

反之，在某些情况下，不使用外键约束与使用外键约束，对某些业务逻辑的性能影响是很明显的。

---------回复--------------

严重支持钻钻，，，

---------回复--------------

偶以前做的一个项目就完全没有外皱起约束，需要关联约束的地方，全部由前台代码保证。

---------回复--------------

我个小屁孩也来说一句：

我觉得外键在很多情况下是必要的，它能让使用者少操很多心。

对于使用者来说，设计合理的外键能大大减低SQL语句的复杂性。

当然，如果外键的存在大幅降低了效率，或者让维护者无所适从的时候，也可以考虑使用其他方法保证完整性。

---------回复--------------

to : libin_ftsafe(子陌红尘：TS for Banking Card)

当然凡事得有度，我们可就这个度做一个衡量。

先说你提到的这一点吧，程序逻辑对数据完整性的检查和使用外键作为对数据完成性检查的优缺点。

---------回复--------------

外键多复杂谈不上，不过实际中的逻辑不可能象程序员要求的那样严格，所以还是少用

---------回复--------------

如果程序能做到很严谨，外键少，固然能提高数据库性能，但往往程序的严谨性很难保证，需要合理的平衡外键与性能的关系。

---------回复--------------

前台逻辑保证完整性采用的还是多的

---------回复--------------

需要关联约束的地方，全部由前台代码保证

-------------------------------------

这是很危险的，一个小小的bug或者一次误操作就可能使数据库中的数据违反业务逻辑。

---------回复--------------

相信到这个帖子来讨论的人，都是经历过不少系统设计工作的，今天拿这个很老套的问题出来讨论，就是想把很多问题量化、实例化，答疑解惑，分享经验，以怡后学。

---------回复--------------

to：wgzaaa

“实际中的逻辑不可能象程序员要求的那样严格”
说的很实在。

---------回复--------------

外键 我是经常用的，尤其是关系比较多的主表 与子表关系。

因为代码来维护这个感觉成本太高。

当然对于一些逻辑关系比较平淡的实体，可以忽略。

总之这东西不建议完全抛弃，毕竟是个好东西。

性能损失是有的，适当应用，我觉得挺好的

---------回复--------------

需要关联约束的地方，全部由前台代码保证

-------------------------------------

这是很危险的，一个小小的bug或者一次误操作就可能使数据库中的数据违反业务逻辑。

---------------------

确实如此，那个系统用长了就会产生一些垃圾数据，这些垃圾数据在前台永远都用不到，不过也不影响系统正常运转，，，

---------回复--------------

to： wangtiecheng(不知不为过，不学就是错！)

我试着量化一下吧，这里说到外键的性能，肯定就要涉及到索引的性能，是否可以这么说除了那些不断大量增加数据的表，包含大量历史数据表，要慎重考虑性能，而其它的那些表，则必须要考虑外键。

---------回复--------------

to fellowcheng(鹰击长空)

是否可以用异常来代替那些复杂的逻辑检查呢？

---------回复--------------

外键还是少用或者不用，在程序中判断就很好了

其实就我个人认为最重要的是在开发和测试阶段太多的外键，影响工作，降低效率

---------回复--------------

邹老大快出来讲讲啊

在JavaEye讨论结果:http://database.group.javaeye.com/group/topic/6563