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

Question

如果你能保证你不会直接修改后台？且不会出现任何程序，人为错误的话。。

Answer 1

倾向于第一种,属于法治,
第二种属于人治,不可避免会出许多意想不到的问题,实在觉得影响速度 ,还不如就不要算了!

Answer 2

以下为我引述的一个观点：
“如果你想让用户直接用SQL操作数据, 外键是必要的. 但大多数而言, 用户都是通过应用程序访问数据的. 
在程序中, 涉及外键的应用基本是以下方式. 以EMP和DEPT表为例, EMP中的DEPTNO是foreign key. 当用户输入/更改EMP表的DEPTNO数据时, 通常是列出一个下拉列表, 里面含可供选择的DEPTNAME (隐含DEPTNO). 这个表是程序自动从DEPT表中生成的. 在这种情况下, 用户只能在合理的DEPTNO中选择, 无论如何都不会破坏Constraints. 
即使使用了外键, 在以上所述的情况下, 数据的integrity是靠程序来维护的, 外键并没有起什么作用. ”
这是我与同事的一个争论，我认为即使在速度方面外键约束仍快于自建程序，当然自建程序也需保证完整性为前提。我想以上我引述的那段内容肯定有问题，但未找到（比如并发时），请指点。

Answer 3

其实真正影响速度（其实是在发现不对头时纠正设计速度）的是：在没有好好涉及的情况之下过分想当然地抄袭书本，最后发现想象与实际不一致。自己写代码是一个理论上可以解决一切的方法。但是这是狡辩，谁都明白这应该是最后的没办法的办法。使用外键有“过分”之嫌，当业务需要有灵活性（先输入关联信息再输入被关联信息）时数据库会拒绝。如果你的设计明白指出了（或者从你“通用”的设计过则中继承了），那么你应该尽量使用你需要的任何外键约束。如果你没有设计中考虑到，处于朦朦胧胧的状态，那么应该提醒自己不要随便下结论。