数据库外键的必要性

原文地址：http://tangzhongxin.blog.163.com/blog/static/89219612011929104914408/

数据库外键的必要性，扯蛋！这个时候还来讨论这个问题，就像讨论“我们是否需要穿上衣服上街，还是要大家都在街上祼奔一样”。

从各主要数据库发展趋势

可以看出，大数据库像Orcle，MS SQL Server，……就不说了，它们一直都是。

你说 MySql 不支持，那是 MyISAM 表格式，现在它们默认都是 InnoDB 表格式，它是支持外键的；

你说 SQLite不支持，但它从 3.6.19 版本开始已支持了……

……

…… 只是你的懒惰和习惯而已！！！ ……

---

大家喜欢使用外键吗？  http://www.itpub.net/thread-1313696-1-1.html

正方：代表人物newkid。

主要论点如下

原帖由 newkid 于 2010-6-10 22:48 发表 
记得我不止一次在这里和别人争过这个问题了。 
1. 你的程序再严谨也有可能出现BUG;你自己判断不如交给数据库判断，它做得又快又好。 
    大多数人的程序没有考虑并发问题。一旦考虑了就得手工加锁，效率很低。 
    数据可能绕过你的应用程序进入数据库。 
2. 性能问题：难道你自己做就没有开销？ 
    一个外键判断分摊到事务级别，开销可以忽略，用户完全没有察觉。 
    如果是批量导入数据，可以先暂时屏蔽外键，事后用NOVALIDATE选项快速恢复，前提是你的数据是干净的。 
3. 举个麻烦的例子看看？ 
    外键约束正是为了防止你乱来，这是给你的保护。 
    开车系安全带麻烦吧？有时候它能救你的命。 
4. nyfor说过了可以用延迟约束。但根据我的经验没什么必要。凡是有外键则父亲数据必定先生成。比方说你的入库单，入库明细需要这个单号，那么父亲表（入库单）肯定要先生成。 
此外，外键还会给CBO提供重要的信息，用来生成最优计划。

 

 

反方：代表人物qingyun。

主要论点如下

原帖由 qingyun 于 2010-6-10 13:32 发表 
我不太喜欢外键， 
原因： 
   1.程序逻辑，完整性，我会在存储过程或包等地方做严谨的判断； 
   2.性能问题，这是我最不喜欢用的关键原因，比如一个业务流水表，频繁插入数据，如果这个表身上有3外键，那么每次插入一条，就必须对这3个外键对应的3个表做相应的查找判断有无对应数据，如果这3个表也很大，那就这3个表的判断时间就很常，虽然外键指向的关联表的字段肯定是索引，但是我觉得很多时候，这样的判断本来就在程序里控制好了，通过外键再判断一次，就是降低性能；而且其实有的地方判不判断也无所谓的，但是用了外键，就必须化时间去判断，无论oracle内部多么优化外键对于数据的检索速度，它总是一个不小的消耗； 
   3.维护麻烦，很多公司的软件都是定制的，这种定制的东西，随意性相对较大，项目开发实施过程中，需要经常对表修修补补；还有就是业务逻辑有bug或者其他情况，需要经常手工维护数据，有错综复杂的外键关联着，很是麻烦； 
   4.外键定死了两个表之间数据的先后生成关系，最常见的是单据主从表，有的时候，在生成单据的时候，是先生成明细，再生成主表；如果钉死了外键，这个就没法实现； 
  当然有些关键的业务，确实需要外键； 
为什么说这个话题，我今天把项目数据库建立好后，用了很少的外键，周围同事说数据不严谨，需要错综复杂的那些相同字段名的外键都建立起来，这个我很不情愿； 
比如这个数据库一共100个表，按他们的想法，外键就可能有300个；我晕，太教条主义了； 
如果说让我建300个索引，我很乐意，因为提高运作效率的，而外键只是检测严谨性，对数据库的运作效率只有降低，没有任何提高的可能性； 
其实这只是设计习惯的问题 ，有兴趣大家随便聊聊自己的习惯。

 

 

还有一个反方的声音有独特见解

一起放上来供大家参考

原帖由 ruideliang 于 2010-6-12 14:42 发表 
外键是暴露的,程序是封闭的,同样是经过测试的程序和外键约束,人为因素造成约束失效的可能性谁大谁小,很明显,所以反对使用外键,因为与系统高可用性目的冲突

 

反！

外键是暴露的? 只要绕过你的应用程序登录数据库，还有什么不是暴露的？ 
那你说要不要主键？它也是暴露的，你随时可以DROP. 
表结构呢？是不是暴露的？你随时可以修改。 
这又和高可用性有什么关系？ 
“同样是经过测试的程序和外键约束”： 
外键不用测试。只要你的数据存在这种关系，一个DDL搞定。 
外键同样也可以是封闭的。有一种东西叫做“授权”，不该看到的用户，什么也看不到！在我设计的系统中，客户端只能看到存储过程的接口。