是否应有数据库外键

我的观点是，外键在初始阶段能加的都加上，只有迫不得已的时候才disable或drop掉。遇到性能瓶颈的时候，尽量采用其它方式调优，而不要轻易牺牲掉外键。有外键约束的时候，写程序的确会有约束，但从直觉上说这种约束一定程度上揭示了设计或实现上不合理的地方。带着外键写出来的应用更倾向于严谨。产品上线之前如果确实需要通过牺牲外键达到性能上的优化，再捡相对不重要的外键废弃掉，同时要把这个document下来，下次遇到数据不一致问题的时候，是个线索。两点说明：1. 我们在做的一个项目确实是小项目。  2. 我得承认我最近三年开发都不用关系型数据库，貌似 no sql那么nb的key-value pair存数据，其实这三年在持久层上很多纠结。如果我说的不对，请指正！



下面引用一些有见地的想法：

× 支持外键的：

1. 你的程序再严谨也有可能出现BUG;你自己判断不如交给数据库判断，它做得又快又好。
    大多数人的程序没有考虑并发问题。一旦考虑了就得手工加锁，效率很低。
    数据可能绕过你的应用程序进入数据库。
2. 性能问题：难道你自己做就没有开销？
    一个外键判断分摊到事务级别，开销可以忽略，用户完全没有察觉。
    如果是批量导入数据，可以先暂时屏蔽外键，事后用NOVALIDATE选项快速恢复，前提是你的数据是干净的。

 

也有人提到了如果100张表可能需要建立300个约束，导致性能太差。
我要说的仍然是，是否这300个外键约束都是业务必须的，如果是，没有办法这就是必须要加的，如果不是，那么大可不必在所有的地方都增加外键。
如果在程序中仅对其中的5、6张表的10来个外键约束进行判断，然后和数据库中的300个外键去比较，并评价Oracle的外键性能太差，恐怕是有失公允的。

 

× 反对外键的：

的确外键在大系统中用的很少，在开发初级，设计数据库的时候一般会加入外键，以保证系统设计的完整性和业务需求的完整性，也便于开发人员了解业务规则，在程序中加以控制，很多大系统在系统稳定后，会逐步将外键去掉，以保证性能，将太多的功能强加于数据库，虽然说数据库很强大，但是毕竟很多人不信任数据库的能强大到什么都能干的地步。所以在一个大系统中外键见的少也不足为奇，小系统就无所谓了，用不用外键取决于设计人员，这样的系统也随处可见。





另引用一篇：


数据库设计是否需要外键。这里有两个问题：一个是如何保证数据库数据的完整性和一致性；二是第一条对性能的影响。
正方观点：
1，由数据库自身保证数据一致性，完整性，更可靠，因为程序很难100％保证数据的完整性，而用外键即使在数据库服务器当机或者出现其他问题的时候，也能够最大限度的保证数据的一致性和完整性。
eg：数据库和应用是一对多的关系，Ａ应用会维护他那部分数据的完整性，系统一变大时，增加了Ｂ应用，Ａ和Ｂ两个应用也许是不同的开发团队来做的。他们如何协调保证数据的完整性，而且一年以后如果又增加了C应用呢？
2，有主外键的数据库设计可以增加ER图的可读性，这点在数据库设计时非常重要。
3，外键在一定程度上说明的业务逻辑，会使设计周到具体全面。
反方观点：
1，可以用触发器或应用程序保证数据的完整性
2，过分强调或者说使用主键／外键会平添开发难度，导致表过多等问题
3，不用外键时数据管理简单，操作方便，性能高（导入导出等操作，在insert,   update,   delete   数据的时候更快）
eg:在海量的数据库中想都不要去想外键，试想，一个程序每天要insert数百万条记录，当存在外键约束的时候，每次要去扫描此记录是否合格，一般还不止一个字段有外键，这样扫描的数量是成级数的增长！我的一个程序入库在3个小时做完，如果加上外键，需要28个小时！ 

结论：
1，在大型系统中（性能要求不高，安全要求高），使用外键；在大型系统中（性能要求高，安全自己控制），不用外键；小系统随便，最好用外键。
2，用外键要适当，不能过分追求
3，不用外键而用程序控制数据一致性和完整性时，应该写一层来保证，然后个个应用通过这个层来访问数据库。