了解到很多公司禁止使用外键，现在使用关系型数据库是否还应该使用外键、触发器、存储过程等？

[Feiox]

没企业工作经验的人特来讨教 ~
感觉，没有关系的数据库还是关系型数据库么 ~

[fengchang]

互联网公司，一天改三次需求，哪敢用外键

[xuwenmang]

这问题，我起码见过20次了。。。

[princeofwales]

我们公司禁止使用触发器，外键用的少，存储过程不多

[huobazi]

外键是给 学生选课系统 用的

[line]

外键，触发器会带来不必要的麻烦和性能问题，可以理解， 但为什么不能用存储过程？

[huobazi]

@line 会有人把业务逻辑写到 sp 里 到处坑

[iroy]

sql写得好，人生没烦恼 XD……我也不喜欢搞 FK，感觉太麻烦了。。。

[viator42]

不用外键，触发器从来没用过，存储过程偶尔会用，尤其是涉及到钱的业务。

[zhtubo]

存儲過程還是要用的

[tabris17]

我们公司还禁止表名字段名里带下划线呢，自以为是的傻逼到处有

[xfwduke]

mysql里面下划线是通配符
处理不好会造成权限异常

不让使用, 并不算很无厘头

[HowardMei]

@akira 可以是可以，但反过来更好吧，FoundationDB就把Nosql当SQL用，Amazon和Google应该也这么做了，扩展性Nosql天然优势。

[wenbinwu]

求相关知识的文章

[jjx]

看应用场合的, erp类数据正确性第一位,没有事务，没有外键，那是找死，　不用外键就意味着自己要处处检查, 而且也没有办法确保一致(比方说前面检查produt_id上正确的,后面有人把这个product_id的记录干了, 你还是会存一个错误的ｐｒｏｄｕｃｔ＿ｉｄ，　再说了，你检查product_id还是要查数据库的，当然有人说，可以放缓存，查缓存，但这你必须确保缓存有一致性．．．．．), 放给数据库是合适的

[zhicheng]

对于各种射交应用，多复杂的关系不用外键都无所谓，反正错那么几百万几千万条记录也没人 care。
对于金融，电商等不用外键有点儿捉死了。
理解各种数据库的并发锁，事务的隔离级别也很重要。
一般情况下为了避免 debug 的时候太纠结，我全部使用最严格模式。
至于，触发器和存储过程，持保留意见，我写的全部应用都没有用到过。
出于两点，
一是SQL的语法有点儿诡异且不可移植。
二是不喜欢同时使用Python和SQL维护数据逻辑。

为了使 RDBMS 健壮好用我有个规则，最少功能，最大约束。

[ant_sz]

如果：
1. 你的应用数据量很大，而且进行的分库
2. 你的应用对于数据一致性没有太大需求，某一个映射关系没有做对不会影响大局
3. 你的数据写入频繁

那么你应该考虑放弃外键。

如果：
1. 你的数据对数据一致性要求很高
2. 你的数据量不算很大
3. 你的数据写入不频繁

那么你完全不应该放弃外键。

绝大多数情况都满足后者的条件。也就是说很多不必要放弃外键的场合因为对外键性能的过度担忧而放弃了。这是不好的。

在对数据一致性要求很高的场合不使用外键是一种非常非常非常脑残的行为。因为这迫使程序员手动维护数据一致性，而程序员写出 Bug 的可能性远大于 Database 在这个问题上出 Bug 的可能性。而且，最让人无法理解的是，在大多数情况下，在外部编程语言（如PHP，Python，Ruby 等）当中手动维护数据一致性，往往性能是低于数据库自己处理的性能的。

不分场合强迫放弃外键就是耍流氓

[min]

是不是你们用的数据库功能太搓了？
自己写的约束检查逻辑都比他自带的强

[typcn]

一直不知道外键，就用过一次触发器是开了个 MC 服务器写金钱系统，把用户表（网站用）中的积分跟游戏表（插件自动创建）中的积分进行同步，但是又不好动代码，就用触发器了。

Google 了一下发现外键的功能我基本上都是用程序写的。

[cevincheung]

搭建过一次cluster，因为有存储过程、外键、触发器，所以就挂了。配置起来忒麻烦还是在代码里控制比较好。

[JamesRuan]

同意不用外键不如用nosql的观点