是否应该建外键的讨论

http://www.iteye.com/topic/124612
http://www.iteye.com/topic/2832
http://www.iteye.com/topic/8283
http://www.iteye.com/topic/151187
http://www.iteye.com/topic/2312

http://www.itpub.net/viewthread.php?tid=510215&extra=&page=1

以下摘几个我自己认同的观点:
1, 其实有一段时间我们的开发人员也有这种想法，以为程序可以控制好
后来发现没有外键的表里经常有垃圾数据（找不到父亲的孩子），然后又把外键一一加上去，后面测试才发现是应用的BUG，在特定情况下才会发生的BUG。
如果没有外键那数据库就不会报错，也就是说垃圾数据不能阻止。
2,在复杂的业务逻辑下，程序来保证这个是极不可靠的，只有交给数据库从底层来保证才能避免出错。
当然，如果是稳定的程序中把外键去掉会怎么样，这又是另一回事了。
外键的存在对数据库的维护来说是有一些不方便的地方。
3,我们以前做开发的时候，在开发、测试阶段，是所有业务逻辑需要的外键都加上的。数据量小，并发少，也无所谓什么性能什么的。等测试和试运行一段时间后，再将外键去掉，以提高性能。
4,怎么这么多人不用外键的，外键可是逻辑的约束啊！说外键影响性能，可以denormalize外键表啊，但是插入更新必须要符合约束啊，我觉得这是不可替代的啊
对数据的约束最好尽可能放到db里，集中管理清晰准确，以前吃过应用管理约束的亏，不过好好看看oracle sap这些范式做的都还不错啊，他们都这样做我想多少能说明点问题吧
5,你看看oracle系统数据表的设计,再看看大型数据库表的设计,
你就明白,外键约束无处不在.
6,该用的地方，就一定要用！前几天我们的应用程序发现一个bug，后来我仔细一查，就是由于没有使用外建，数据不匹配导致的。教训深刻！
7,如果现在要我来选择，我决定是要用的一定要用，这是系统设计的严谨性的要求，不然产生一堆垃圾数据，这是在一个好的系统中是不允许的。
8,呵呵，做过开发的ＤＢＡ应该都会有这样的体会
当统计报表中的数据不对的时候就知道什么叫问题严重了，要一点点数据去核查。
9,最好还是使用数据库外键这个最直观的功能吧
至于性能不知有没有什么测试数据，究竟能慢到什么程度，不要听说会慢就不用吧（呵呵，从ＴＯＭ的书里学到的）
10,这要看是建立那中类型的数据库了
如果是操作类型的数据库 OLTP 面向应用的
数据的规范化是很有必要的.. 该用外键的情况一定要用.
如果是面向部门 用于OLAP或建立数据仓库.
这种时候 往往需要反规范化 存取效率是首要因素

我自己的结论:如果是做企业级的OLTP应用，并且数据量不是非常大的话，一定要建外键。毕竟对于企业来说，保证数据的正确性是最重要的。但如果经过长时间的运行证明代码可靠、并且数据量已经很大，这时也可以去掉外键以提高运行速度。

评论

1 楼 kilobug 2009-04-22  

受教了！！！