关于数据库设计中主外键约束的一个困惑

显示全部楼层 · 2012-5-21 10:19:41

主外键约束，是关系型数据库的最主要特征之一。
以前在ORACLE原厂培训时，ORACLE专家说，中国的软件公司，至少有30%的公司在设计数据库时，不做主外键的约束，而是把这种表间约束写在程序里，让程序来保证。专家说，这种做法很可笑，难道这些软件公司的程序编写得比ORACLE还好吗？
最近在用友的ERP产品上做开发，用友大概就属于上面的30%。数据库表间没有主外键约束，这让我吃了不少苦头。两张表，肉眼看一下，应该是可以关联上的，但偏偏关联时没有数据。找了好久，才发现，有外键关系的那张表上的值两端居然有空格！！于是，不得不通过trim(b.fieldname)=a.fieldname来关联。在条件里加个函数，多少影响效率。
用友的架构师来访，我提出这个问题，对方回答：不做表间的主外键约束，是为了提高效率。
这个回答让我很郁闷，难道查询就不需要效率？
想就这个问题，请教于各位！
多谢！

千问 · 2012-5-21 10:19:41

要是做了约束，也有很多不方便
比如修改主键就很麻烦
你要把关联的外键逐个处理

千问 · 2012-5-21 10:19:41

我的观点是应该用外键；主键是不可修改的；万一要修改那也是非常状况，最好停机做一个批处理，而不是在应用中修改的。

千问 · 2012-5-21 10:19:41

原帖由 zhangfengh 于 2009-9-16 12:30 发表
一般的做法是在设计的时候外键要加上，一直到运行平稳，才考虑去掉外键。
严重同意。吃过外键的苦，建议不用于生产系统。

千问 · 2012-5-21 10:19:41

原帖由 zhangfengh 于 2009-9-16 12:30 发表
一般的做法是在设计的时候外键要加上，一直到运行平稳，才考虑去掉外键。
对此我持反对意见。你的意思是等到应用运行稳定了，就可以相信它不会产生违反约束的数据了。在现实生活中，一个应用系统在整个生存周期中都会被修改，可以说没有真正稳定的时候。外键永远给你的数据提供保护。
除了数据完整性之外，外键约束还可以给优化器提供信息，产生更好的执行计划。
反之，我看不到把外键从一个稳定的系统中去掉有任何好处。如果你是指性能上有所提高，那么实际上外键的开销在事务级根本觉察不到。如果你试图在应用中写代码来保证数据的完整性，那么这个代码的开销比外键还大。
在批量导入数据时，可以临时屏蔽外键，事后再恢复。

千问 · 2012-5-21 10:19:41

原帖由 guostong 于 2009-9-16 21:07 发表

严重同意。吃过外键的苦，建议不用于生产系统。
给个例子？

千问 · 2012-5-21 10:19:41

我觉得关键是设计时作为外键引用的列最好不要更新,否则还是不要用的好,对于非常大的表,子表多对一,更新起来还是会有影响的.

千问 · 2012-5-21 10:19:41

具体记不太清楚了，好像是部门和班组要进行重组，导致大量数据不可用，最后决定放弃外键。

千问 · 2012-5-21 10:19:41

原帖由 guostong 于 2009-9-16 22:51 发表
具体记不太清楚了，好像是部门和班组要进行重组，导致大量数据不可用，最后决定放弃外键。
这怎么能怪到外键头上呢？把外键去掉后，虽然不报错了，但你不知道表中有多少垃圾数据。
假如一个部门拆成两个：保留一个旧代码，增加一个新代码；或者新增两个新代码。修改所有相关的子表。
只有外键约束能够保证你的拆分是正确的。

千问 · 2012-5-21 10:19:41

嘿嘿，只能说用友的那位瞎说的，或者糊弄你