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

具体情况具体分析, 绝对化要不得.

不用fk？完全不能理解啊

哪些公司这么搞，姿势很奇特。

@min 一个教我们“大型数据库技术” 的老师，是从华为退下来的。她说，公司里禁止使用外键。。。半信半疑 ~

关系可以通过代码来维护，不过 sql也可以认为是代码。

互联网公司一般都不用外键。传统企业应用也许用的多一些。

使用外键会带来性能问题。我们公司使用逻辑外键，但有些核心地方还是使用真实外键

数据服务器从单台扩展到多台（分库）时会有麻烦吧？

如果不用外键，， 那为何不用nosql

感觉一致性要求高的应用还是用外键会比较好

互联网公司不太喜欢用，企业开发还是喜欢用

因为用那些东西会导致多表锁死。访问量小没事，大了就麻烦了，所以这些东西基本靠程序逻辑进行处理

企业大数据量的应用下，比如单表千万条记录数以上的都不用外键，一般用业务级的代码逻辑来控制。

压力大了以后，MySQL基本沦为文档数据库，基本只有按主键CRUD的功能

外键啊join啊group啊子查询啊基本一用死一片

即使可以通过合理的评估、索引的规划等各种手段来让这些机制能跑得动，但在有成千上万开发的公司里，哪有足够的人来把关呢，还是直接完全禁止比较高效一点

一直觉得用存储过程的都是坑货~

等做数据整合，分库的时候，外键很麻烦，等哭

一直不懂啥是数据库外键。。。后来发现我在程序里写的功能就是实现外键的功能。。。

数据库如果设置了外键，不如在代码进行关联灵活。

一直不懂啥是数据库外键。。。后来发现我在程序里写的功能就是实现外键的功能。。。

数据库如果设置了外键，不如在代码进行关联灵活。

现在还有人用外键啊，不能理解啊，今后系统扩展怎么搞啊，会头疼死，或者大量重构代码啊

谁规定关系型数据库不能当nosql来用的？

我们有关系数据库，外键有时还是用的，但只用在很小的人工生成的表上，一些从log上import进来的表，不可能用外键，只能roll up了用的时候再sp里join或代码上join

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

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

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

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

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

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

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

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

存程是要用的

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

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

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

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

求相关知识的文章

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

外键是个可以程序替代的功能, 而且写在程序能轻松 scale, 加外键等于给数据库增加鸭梨, 而且备份恢复也可能会巨慢

选择关系数据库的关键是事务而不是外键, 记录间事务是 nosql 代替不了的

@huobazi 这也是一种开发方式

灵活意味着更容易出错，不过大多数人写的应用没啥重要的东西，错就错吧

我们公司用MySQL（myisam），不支持外键，不使用事务呢！根据业务场景来使用吧！也不能说绝对，不过楼上哥们说的好，大公司的话确实不怎么使用，首先是移植性，易用性，其次是性能问题，只能说具体情况具体分析了

不用外键就不吐槽了。你们见过一个千万行级别的用户行为表user_id是varchar而且没索引的么。。。。这个表被某官网每天几十万人查询。

@xfwduke 下划线作为通配符是like字符串里的。关表名字段名啥事儿？

@min 当你的数据量达到一定的程度以后，你会发现FK带来的performance影响以及maintain的开销成倍增加。到时候你只想说一句：妈蛋，当时那个SB搞得FK！

互联网公司一般不推荐用，你用了到时要分库就麻烦了。企业应用一般都会用的吧。

我也建议不使用外键，在程序中维护好关系是最好的办法，更好的维护关系。这就需要写代码的人有功底。。。有外键的表，性能，维护都不好做。

@huobazi 把业务逻辑写到sp里确实很奇葩，但也是有理由的。以前做过一个政府的项目，用.NET，甲方对更新DLL控制的很严，经常半年部署不上去。后来项目组就开始努力避免改C#代码，写了一个通用的dispatch，然后把业务逻辑分布在JS，模板语言和存储过程中，成功实现了不更新DLL上线新功能。

@iT2afL0rd 可以分享一下数据库软件是什么吗，数据量大概多少，数据库server硬件是什么

除非绕开sql层，使用nosql来进行数据处理。否则使用外键是数据库系统考量优化和约束的先决条件。这种特性决定了事务中考虑约束，分析中考虑性能。而数据库引擎处理这类问题往往是约束级别高于性能。

一般根据以上原则考虑外键的使用，而不是方便性和移植性。

外键的使用是传统数据库的基础，如果用则需要对使用者有扎实的基础知识。否则的话，都是属于用不好的范畴。

@min 用MySQL，数据量达到100M级别之后就会很烦躁了，硬件就是DELL的R620。