就论速度，外键约束不如自建程序来控制？欢迎讨论。

千问 · 2008-11-14 14:42:19

同意上面说法
我以为自己编写程序来维护数据引用完整性，没有必要，之所以出现这种情况，就我碰到的，都是因为调试不方便，导入数据不方便而放弃使用外键，我个人认为这是不正确的。
也许有的人认为只要我的程序正确，系统运行正常，根本不需要去做完整性检查，纯属浪费资源，但这又如何能够保证系统永远运行正常呢？
我也想听听其他朋友的想法。

千问 · 2008-11-14 14:42:19

也许下面的论点会招来大家的砖头, 但是不吐不快!
在论坛里已经混了一年多了, 经常看见有"高人"在说不用数据库或其它系统软件所提供的功能, 用自己写的代码, 这样不仅维护起来方便, 而且速度更快! 甚至可以看到这样的观点-是否oracle都无关, 只要是数据库!
不知道诸位在oracle上编程的时候是否想过这样的问题:
为什么用数据库管理系统(DBMS)来存储及管理数据?
为什么用关系型数据库管理系统(RDBMS)?
为什么用oracle公司的数据库产品? 其它公司的数据库产品是否也可以?
如果自己编制的程序真的数据库无关, 为什么不用更廉价的数据库产品, 而使用昂贵的oracle公司?
在编制程序的时候, 是否应该更加关注数据库产品或其它应用产品提供的功能, 更加合理的应用这些功能?
我以前公司的老板曾经说过这样一段话: 不要总认为是别人产品的问题(专指oracle), 要注意自己的问题! 美国的信息化比咱们国家至少要先进3-4年, 咱们现在遇到的问题, 人家3-4年前就遇到了, 有许多问题是可以用数据库的技术解决的!
也许这段话有些崇洋媚外, 但是其中还是有些道理的.
我想, 如果这些问题想明白了, 楼主的观点就会很明了了!
GOOD LUCKY!

千问 · 2008-11-14 14:42:19

我们公司用的外键很多，但是确实很影响性能，并且数据库很不好维护，当对数据作update,delete时会检查外建，如果数据量很大，很痛苦，如果你是遇到这种情况就会体会到痛苦的地方了，我问了很多开发人员，基本都是通过程序控制，但是，这样对程序员要求高了，他们必须懂得业务关系。用外键是一个省事的办法，对程序员要求不用很高。

千问 · 2008-11-14 14:42:19

我一直在考虑这些问题, 以下为一点想法.
如果你想让用户直接用SQL操作数据, 外键是必要的. 但大多数而言, 用户都是通过应用程序访问数据的.
在程序中, 涉及外键的应用基本是以下方式. 以EMP和DEPT表为例, EMP中的DEPTNO是foreign key. 当用户输入/更改EMP表的DEPTNO数据时, 通常是列出一个下拉列表, 里面含可供选择的DEPTNAME (隐含DEPTNO). 这个表是程序自动从DEPT表中生成的.在这种情况下, 用户只能在合理的DEPTNO中选择, 无论如何都不会破坏Constraints.
即使使用了外键, 在以上所述的情况下, 数据的integrity是靠程序来维护的, 外键并没有起什么作用.
我不肯定以上是外键应用的唯一情形. 欢迎大家提出各种情形, 具体分析.

千问 · 2008-11-14 14:42:19

论速度当然是自建程序快，原因很简单，如果某种方法不快，换一个方法就是了。
象insert是如果要用到一个产品名单，本来这个名单从某表里select出来，大家嫌慢，干脆把这个名单就做在前台软件里， hard-coded算了。至于这个名单多久更新一次，如果有人负责不是问题，负责那人走了，也许就没人知道了。
外键的主要作用之一是维护数据的逻辑完整性，如果前台程序好当然没问题，不过如果环境比较复杂，不能完全控制所有进入数据库的进程时，用外键可以很有效地保护数据完整性。
这是性能和安全性之间的平衡，最好当然是两者结合，以前见过一个公司搞一个online market, 他们坚决拒绝用外键，认为自己的程序检查数据是完美无缺的，结果在测试阶段数据就混乱得一塌糊涂，他们的测试员在测试的时候都是百万富翁，自己卖东西给自己就能赚钱

后来要从头检查程序里的逻辑关系又太复杂，谁也不知道那个地方又藏着一条什么规则，结果倒闭了事。

千问 · 2008-11-14 14:42:19

最初由 evanzou 发布
[B]我一直在考虑这些问题, 以下为一点想法.
如果你想让用户直接用SQL操作数据, 外键是必要的. 但大多数而言, 用户都是通过应用程序访问数据的.
在程序中, 涉及外键的应用基本是以下方式. 以EMP和DEPT表为例, EMP中的DEPTNO是foreign key. 当用户输入/更改EMP表的DEPTNO数据时, 通常是列出一个下拉列表, 里面含可供选择的DEPTNAME (隐含DEPTNO). 这个表是程序自动从DEPT表中生成的.在这种情况下, 用户只能在合理的DEPTNO中选择, 无论如何都不会破坏Constraints.
即使使用了外键, 在以上所述的情况下, 数据的integrity是靠程序来维护的, 外键并没有起什么作用.
我不肯定以上是外键应用的唯一情形. 欢迎大家提出各种情形, 具体分析. [/B]

但有没有考虑并发性的问题那，如果下拉表很早就已经弹出，而用户迟迟没有作出选择，当用户再选择时，并不一定能保证隐含的deptno还有效。
总是听人说通过程序控制比较好，可是我总是想不出有什么方法来控制并发性，难道要在自己的程序中通过加锁来控制到数据库的操作吗?
希望能有人举一些比较简单而又能说明解决方法的例子，谢谢

千问 · 2008-11-14 14:42:19

最初由 evanzou 发布
[B]我一直在考虑这些问题, 以下为一点想法.
如果你想让用户直接用SQL操作数据, 外键是必要的. 但大多数而言, 用户都是通过应用程序访问数据的.
在程序中, 涉及外键的应用基本是以下方式. 以EMP和DEPT表为例, EMP中的DEPTNO是foreign key. 当用户输入/更改EMP表的DEPTNO数据时, 通常是列出一个下拉列表, 里面含可供选择的DEPTNAME (隐含DEPTNO). 这个表是程序自动从DEPT表中生成的.在这种情况下, 用户只能在合理的DEPTNO中选择, 无论如何都不会破坏Constraints.
即使使用了外键, 在以上所述的情况下, 数据的integrity是靠程序来维护的, 外键并没有起什么作用.
我不肯定以上是外键应用的唯一情形. 欢迎大家提出各种情形, 具体分析. [/B]

但有没有考虑并发性的问题那，如果下拉表很早就已经弹出，而用户迟迟没有作出选择，当用户再选择时，并不一定能保证隐含的deptno还有效,就算到那时候，可以在程序中先查出是否该deptno有效，可是再怎么样，还是有个时间差的，难道要在自己的程序中通过加锁来控制到数据库的操作吗?

千问 · 2008-11-14 14:42:19

如果有合理的索引存在，不认为FK速度会比程序自己检查慢
那仅仅是一种想法，一种感觉
流传的欺骗了我们的感觉的东西多的去了
就比如到处流传 count(1) 比 count(*) 快的多一样
很多时候，只是编码和设计的人，不理解数据库，用不好数据库而只好自己笨拙的去制造麻烦而已