leader 竟然让我们用外键

不爱用就换一个不用的公司

辩证的看外键，它的确方便了数据的关联，缺点是在数据上量之后会引发严重的效率问题，所以如果一个项目可预期的完全没有这方面的顾虑，为什么不上外键呢

没经历过大项目的偷懒小领导

用了有什么坏处吗？

你这个不是厌恶感
是优越感

为了工资，屎都能吃。

没有什么范式的，只有合不合适，你可以跟你 leader 提，只是别说别人不用就好了。我倒觉得没所谓。

别把互联网那一套东西当神了，有多少应用的量级达到那些互联网厂商的？

@Hstar 数据量一定会大起来的 用户有银行的.

@shifttacn 倒真不是优越感 , 只是实际开发和我原来学到的在进行冲击

@wangxiaoaer 有道理

@b821025551b 哈哈 反正我不太愿意为五斗米折腰

不用外键是考虑到日后 scale out, db 做 sharding, 不是所有项目都有这个需求, 外键有外键的好处, 现在用了日后改造也不是不行, 能活下去的项目没有一步到位的.

@Just1n 第一个问题 外键在设计初期肯定是没问题, 但是随着发展,外键出现了很多问题,性能上的 数据完整性的....所以为什么不在业务层解决呢?
第二个问题 厌恶感就是觉得有人让你接受 /并且使用你不喜欢的东西
第三个在第一个中提到了
第四个 没问诶
第五个 这个随便百度一搜能搜出来一万个缺点吧
我觉得不是一昧的接受 我是觉得确实有道理才接受的啊, 形成了"技术价值观" , 而且我拒绝存在及合理这个概念

@monsterxx03 是哦

外键很痛苦而且外面的趋势是不用外键,你现在返祖归宗的代价就是与时代格格不入
如果你还想为了以后的发展,建议离职
上面说外键好的基本上技术是不会革新的,35 岁淘汰说的就是他们

先思考下你以前学到的是不是对的，为什么不用，什么情况不用，而且 mysql 这么成熟的一个数据库，既然他留着这个功能那就是有道理的。

不要少见多怪，过早的优化是万恶之源。

淘宝的第一个版本是 lamp 架构（看子柳的书），几乎没有遵循绝大部分现在的“阿里开发手册”。

既然存在外键，肯定有适用场景。

请各位不要拿"存在即合理"来说事了 , 存在即合理的"理" 是技术慢慢发展变化的理,而不是说技术的理

现在的人这么浮躁吗？
你在 jd 不允许用外键，就任何地方就不能用外键了？
你知道为什么不允许用外键吗？你做了需求分析，SQL 仿真了吗？
你代码抽象了 DAO 吗？以后改不是分分钟吗？

诶居然还整成玄学了？

@binux 你要证明我是错的 ,那你先证明你是对的. 你拿出外键好用的点拍在我脸上 把我拍服气

你评估过项目数据的数量级吗？评估过适用范围和业务复杂度吗？评估过公司能够投入的资源吗？用不用外键是个取舍的问题，如果项目数据量级不打，但是业务极其复杂，用外键可以大大降低设计难度，也就大大提升了开发效率，海量数据场景下不用外键是我们的共识，但是如果你的项目不是海量数据呢？过度设计是非常不好的行为，我们都该注意避免这一点

日后量上去了，总会重构的，到时候，卡点会是这个外键吗？让人头痛的只会是以前没有规范化的代码而已，所以完全不必厌恶啊，外键并没有那么惹人厌的程度

为什么要用？
为什么不能用？
用了会有什么后果？
这个后果是否可控或者忽略？

六字真言送给楼主。

要么你摆事实说服你的 leader 不用外键，要么就听 leader 的。

这两天 v2 咋了？ 各种人各种不顺心抱怨

Django 在数据库层用了很多外键，不过在 ORM 层做了全面的处理。

不用 ORM 的时候我用 sqlite 建表的时候，我就不喜欢用外键，只是不想做太多数据依赖的处理，其实就是懒。

还要怎么反对外键的合理性？

@InkAndBanner #15
一，性能上的，数据完整上的哪些问题？ 你有没有实际经历或者遇到过这些问题？还是只是在 JD 接受到的教育或者是搜索引擎搜出来的问题？
二，这可能不叫厌恶感，这跟每个人的性格有关，也是每一个成熟的职场人必须要学会接受和解决的问题。
三，我承认搜索引擎很伟大，谷歌百度能搜到的一些问题和分析都是前人经过大量的实践猜出来的各种坑。这些搜出来的内容在大部分的情况下是正确答案，但是在很多业务场景下又是不那么“正确”的答案。说白了，就是两面性的问题。

https://stackoverflow.com/questions/2557512/pros-and-cons-of-programmatically-enforcing-foreign-key-than-in-database 是我以 DB foreign Key pros and cons 作为关键字，在谷歌搜出来的排名第一的 StackOverflow 上的结果，你会发现最佳答案是推荐使用外键的。
那么这是不是跟你从百度搜出来的或者 JD 接受的教育是不一样的呢？
我不好说谁对谁错，只是使用场景不一样，就像 SO 上那位说的那用，很多时候我们觉得数据库性能有问题，大部分的情况下是因为我们对数据库了解得还不够深入。

你或者再可以往这方面去想，JD 可以不用外键而用代码去控制，是因为他们的程序猿的能力很强，可以 100%确保代码不会有 bug （外键相关的 bug ），也不会有脏数据的产生，但是你现在所在的公司，程序猿的整体能力可以达到这样嘛？

回答你的问题：
1. 你不能武断的觉得 JD 就是对的，你 Leader 就是错的。
2. 职场玻璃心需要自己去克服和调节。 （这里玻璃心不是贬义的意思，就是描述一种现象）

楼主你需要更深入的去思考你所遇到的每一个问题（不仅仅是技术问题）。

其实无所谓的，不过一般确实不用外键

现在新项目,有人设计的时候用了外键.我说了还不听,已经预计到了很多坑了...哎,那些说存在即合理的,可能是自己的博客项目吧

@Just1n 你其他关于独立思考以及对错的建议我是接受的,但是你举得这个例子我觉得有争议，不足以支撑你的观点。
首先里面最高赞只有 14 赞就不说了 , 况且他里面也提到了"If you index properly, there should not be any performance advantages to foreign keys."
虽然我觉得例子不足以支撑，但是您下面提到了两方面（性能和代码控制的风险）确实说服了我。。。。。

用呗 我记得我当时 SSH 的时候也是用外键

但是我还是觉得外键现在已经是很鸡肋的东西！ [倔强脸]

@Just1n jd 的，三方面。千万行的表很常见，效率差。hash 分表后外键失效。减少 db 层面业务依赖。

不仅外键，blob、存储过程、超长索引、sql 运算，都是明令禁止的

抛开剂量谈功效就特么是耍流氓。。。数据量大，业务忙的时候外键真的有可能成为业务的瓶颈；但业务不大的时候随便上。

外键并不是鸡肋的东西，只是互联网场景下的性能要求及频繁地改动造成了它的鸡肋；你看看银行项目，哪个敢不上外键，出事了分分钟追责。上不上外键，是针对具体的侧重点来定的，而且和你也没啥关系。作为一个搬砖的，要有搬砖的觉悟，工头让怎么搬，就得跟着怎么搬，就酱。

@b821025551b 赞同~

说白了，就是现在不想搞（厌恶一点），以后出了事又得搞（厌恶二点）
所以，还是六字真言送给你

@InkAndBanner #12 年轻人 还没有经受社会的毒打。。

不考虑性能的情况下, 用外键可以使得你不考虑数据一致性的问题

性能与数据一致性的权衡。用部分性能代价换取严格的数据一致性。

建议看一下高性能 MySQL，扩展一下思维。

既然楼主应届生，建议不要考虑工资，这是多么难的练手机会呀，多么好的学习机会呀。有人花钱请你学习，为什么还挑三拣四的？ 建议楼主强烈支持上外键的版本，等什么时候出问题了，再强烈建议做重构，取消外键，这样就知道两种版本的区别，为你下次跳槽积攒了多么重要的经验的，关键是有人花钱请你学习呀，还不用承担后果。

最好，强烈鄙视楼主，身在福中不知福。

广听言论，多思考背后的逻辑，不要被 JD 的思想潜移默化

「看山是山，看山不是山，看山还是山」

教条主义是工程师的大忌!

@18ac0877 有道理，学习了

用不用外键都是根据业务场景决定的，不是死知识。

一圈怼楼主的，就问一句，你们的项目用了外键了吗？

emmm 你们说的外键是建表的时候用的外键约束，还是比如 a_table > id , name b_table> id,a_id,other_info 这种情况下的 a_id ？ 俩的区别是第二个没有做外键约束，，只是查询用的。。范式化？？忘了都- -

小规模的项目完全可以用外键

额，本来想怼楼主的，一度以为一对多就是外键了，慌了一下。查了一下 mysql 文档才发现，外键是 foreign_key 是数据库层面表与表之间的强关联，我还真从大一开始就没用过这个，接手过最烂的项目也没用过

其实这种银行项目，为什么要物理删除，采用逻辑删除，就不存在外键的问题啊

不同领导有不同要求，适用时代才是生存之道。

@Just1n 接口让前端定义还是后端定义、多服务的数据整合让前端处理还是后端门面处理、用 Java8 还是用 Java11，这些是没有定论要看情况选择的。但是，“用业务上的约束还是数据库外键”，跟“面向对象还是面向过程”、“基于领域模型还是基于 CRUD”、“代码编程还是数据库编程”、“用模板还是用 JSP”这些问题一样，是有定论答案的，即：只要有能力有条件用前者，就不能用后者。

虽然你不啦不啦了一大堆，但是你是站在 DBA （或者不混程序员社区的老程序员）的角度上看问题的，并不是在程序员的角度上看问题。推测原因：
一、楼主年少只在 JD 实习过，拿 JD 的经验来说事，你就认为只有 JD 是这么干的；然而事实是，不管是培训班，还是复制粘贴博客，还是大厂里的正式规范，数据库外键都是严禁的（例：〔阿里编码规约〕 [强制] 不得使用外键与级联，一切外键概念必须在应用层解决）。
二、你在 SO 的搜索关键字是“DB foreign Key pros and cons”，然而要是程序员搜索，关键字是“program or db foreign key to make constraint”

@b821025551b #31 我没做过银行项目，但是能猜的出银行即使用了数据库外键，仍然会有其它手段去做约束，因为即使你用上了包括外键在内的所有数据库上的约束手段，那还是不如一份严格的测试报告保险。数据库外键对于银行项目来说，只能算作锦上添花的保险设施，并不是必要条件。

无所谓，跟着 leader 走，技术干不翻他就活该好好听话。什么时候自己是 leader 才能让别人听话。

外键好处：
1，部分框架自动生成关联 Model，代码更少。
2，强约束，不会出现类似删除父级，子集还在的情况。

外键坏处：
1，部分外键字段其实业务上本身就是可以选的；
2，默认没注意就嵌套删除；

为了数据的安全，目前我这边的做法：
1，只有软删除，不允许物理删除，甚至可以考虑不开放删除权限账号；
2，一律不用外键。

你想某人删除一个用户，结果将所有交易纪录，访问记录都 xxx 了，多恐怖啊。

说外键性能差的，连数据库原理都不清楚，而且写程序没有动过脑子。

Django 小项目用外键有多爽你知道么~

@JasperYanky
给客户做的项目，
一定记得模型设置不嵌套删除，
否则。。。有一天会出大事情。。。

没必要因为用不用外键吵架。工程问题我们就应该从工程的视角去分析、判断。不要因为个人的喜好影响客观判断。

外键的作用就是在数据库层面描述表间关系。在这个基础上，提供了数据完整性校验的功能。

那么我们可以分析一下为什么互联网公司用外键的比较少了：

1. 业务没有定型，频繁修改数据库结构。有外键在修改数据结构时会比较复杂。
2. 数据结构简单，甚至退化成日志型。这里强调写入速度，外键提供的数据完整性检查会影响写入效率。
3. 有外键的情况分库分表会比较难处理。

那我们什么时候应该用外键呢？

1. 数据完整性要求严格。
2. 业务模型稳定的情况。
3. 软件开发的流程不完善的情况。从我的从业经验上看，文档能及时更新的团队真的不多。这种情况下，需要一个工具来快速理解业务结构。这时候，带有外键的数据库，我们有大量的工具来进行分析。

临时想到的就这么多，有补充的话请 @我。

简单问一句
数据库为什么有外键？是闲得没事搞出来的吗？
外键存在就有他的道理，用不用是看业务需求和个人喜好
最后一句最重要，，
个人喜好！

@18ac0877 hhhhhhh 老哥思路清奇啊

不管什么项目 开发阶段都可以把外键加上，方便日后维护，现在项目关联关系乱七八糟

没想到我这个小菜鸡随意的吐槽会有这么多大佬围观，诚惶诚恐。大家说的其实都道理，提到了很多没想到的点，真的受益匪浅。
单从技术角度， 我还是比较赞同 @passerbytiny 的想法，只要有能力，就尽量避坑。
从业务上和项目的体量上，在特殊的场合，外键也有一席之地。
从社会角度看。。。。。我一个底层小码农。。。人家让用啥就用啥吧。。。。
可能因为曾经实习的单位还不错，小码农开了眼界，但是没能留下，导致工作在小公司。这种落差感才是痛苦的根源吧 hhhhhhhhh 还是努力工作吧，积极提升自己，往 DreamCompany 一步步蹦~~~

如果你的客户是银行，那还是安全性第一，不要全按互联网公司的经验

我也很抵触外键，数据量大了之后会有性能问题，感觉这个功能比较鸡肋。

不过我在公司一般都是比较佛系的，干活拿钱，不纠结一些没有根本性差别的东西。

现在让用外键就用外键，到时候遇到问题了 leader 要改就再改喽。干啥活都是干，不用外键也不会让你闲下来，也是各种 todo list。

哈哈哈哈哈返祖现象

看适合不适合，不同的用户量，整个服务都完全不一样。

@passerbytiny 我觉得这个定论过于草率了，项目设计阶段，按照“只要有能力必须上更有扩展性 /可维护 /性能好的设计”这种定论一定是非常过度设计的，关键点在于我用了外键 /CRUD 能节省 20 人天，这些人力就可以更好地确保项目进度正常进行，减少 bug，少砍功能，让项目和公司更大可能活下来，这就是项目刚启动 /公司刚创立时的逻辑，例子就是 ROR，框架里到处都是外键的影子，但是仍然是硅谷创业公司最喜欢的框架，也是很多大厂用来实验原型的框架，为啥？可以一个人当五个人用。而如果“只要有能力必须上更有扩展性 /可维护 /性能好的设计”这个定论真的存在的话，每一个架构师 /leader 都得考虑，如果我用了低扩展性 /不好维护 /性能不好的设计来换取开发时间的话，将来项目真做成了需要性能的时候我会不会成为千古罪人呢？
说实话我还真没见过这么想的架构师 /leader，项目没成功的时候尽量先紧着进度来，项目成功了拿公司的钱重构，这基本上就是一个技术选型通用的标准，我甚至觉得这个事情没什么可以讨论的，毕竟一个用了所有扩展性 /可维护 /性能好的设计的项目，最后没做起来，也还是 nothing.

能不能外键先用着，如果数据量上去了要拆，把外键再移除掉？

@calpes ror 里哪里到处是外键的影子？ web 框架跟数据库有什么关系

@helloworldgo activerecord

问个问题: 究竟是"外键导致数据库性能变差", 还是"MySQL 的外键实现糟糕, 导致性能变差"?

从这个帖子可以看出来很多技术型驱动公司为什么东西没做出来就死了

楼主你们公司太没有格调了，不思进取，陈故守旧，赶紧找下家吧

外键本身可以保证数据一致性，只是在读写压力大的时候外键也会成性能瓶颈。所以小项目上外键，大项目能承受无外键的风险自然可以上，毕竟能换来更好的性能。总之用不用外键都是要看场景的，并不是好不好的问题，只是合不合适。盲目追求别人的做法意义不大。

@calpes Rails 直到 4.2 才加入了数据库外键约束。
在这之前不都是无外键然后让程序逻辑来约束外键的吗？
https://edgeguides.rubyonrails.org/4_2_release_notes.html#foreign-key-support

这楼说的是数据库外键而不是逻辑外键哦。

用不用外键，视情况而定。如果外键是洪水猛兽，那数据库为啥还要保留这个功能？

@wysnylc 楼主你那个不是优越感，看看这个才是优越感爆棚啊，哈哈哈

@calpes 嗯 但是 activerecord 的外键，跟这说的不是一个东西吧, ror 里面是逻辑上的外键，数据库上可以不设置为外键，这块是数据库里面的 FOREIGN KEY

是你已经离职了的 jd 给你评绩效，还是你的 leader ?

工作 8 年，只有第一家公司用了外健，数据库是 oracle。
辩证的想，用外健的优点是方便级联操作，缺点也是如此。

有外键,级联的确方便
不过用了外键..一些骚操作就不好搞了..

@msg7086 哥 9012 年了，Rails4.2 是 2014 年发布的，那时候我还没毕业

@helloworldgo 你应该也停留在挺早前的版本了，ActiveRecord::Migration 早就加入添加 foreign_key 功能了，建表时直接生成对应的 foreign_key

都是猿思维啊！当然技术上越优化越好，但公司要赚钱要提高效率要提交客户，先拿出来东西拿到钱，后面慢慢来就好。。。

v2 上真的主要都是互联网的老哥们，企业 IT 开发用外键不是很正常的嘛。 开发不是只有互联网啊。
企业用 Oracle，SQL Server 居多，业务非常复杂。 一套系统用个十几年。 有些应用的 SQL，是自动生成的。
我见过自动生成的 SQL 保存为文本文件有 2MB。 各位如果有用过 Oracle EBS 套件或者 SAP 开发的，就知道企业 IT 真的高度依靠数据库的稳定性和强大的优化能力。各种奇葩的 SQL 写法，用 MySQL 早就呵呵了。 Oracle 单库几个 T 的数据量还是没问题的。 哪有那么多的所谓大数据。 互联网公司讲究快，系统先上线了再说，谁知道公司能活几个月。 很多小互联网公司，真的是业务又简单，数据量又小，因为没用户啊。 开了一年不到就换项目。不就自我感觉技术用得新了点，看不起这个看不起那个。 骚包的很。 大家都容易一叶障目，在自己熟悉的领域做久了，就以为外面都是这样的。我在互联网和企业 IT 都做过，看到这个话题，想法多了点。望海涵。

@calpes 是的，好久没有用 ror 了

@monsterxx03 #14
@OldHu #90
V 站一谈 RDBMS 感觉默认就是互联网大量级+MySQL。

例如很多人默认 foreign key 和 partition/sharding 不能并存，其实只有 MySQL 是这样。
掏钱用 Oracle Database/SQL Server 就可以并存了，不想掏钱 PostgreSQL 12 也完全支持了。

而且外键影响性能比较厉害的也是 MySQL。。。。。。

可以说中国互联网的几乎所有数据库 best practice 都是通过 MySQL 总结出来的。
总结成一句话就是别把关系型数据库当关系型用。
那么何必上 SQL，直接 NoSQL 多开心。

对于外键影响性能这点我一直持保留态度，如今的传统互联网项目的结构性数据都不一定有 20 年前的银行这类传统大型企业数据量大。
而当年那些企业哪个不用外键？ 如果性能影响真的大，当年计算性能比现在低那么多肯定早就有公司和产品将不用外键推广出来了。


外键对于如今而言最大的缺点其实是灵活性，曾经许多方法和算法为了高性能都用存储过程写到了数据库里，而这些年在互联网企业的示范下我们将这些都挪到了后端代码里，并且从前几年就开始流行将代码再向前挪GraphQL，因为性能其实没那么吃紧了， 大不了找方法做横向扩展加机器嘛。
而这个时候对于业务层而言，后面那些层就仅仅是提供数据的，只要准确快速即可，业务层自己是就是全功能的，自己来给用户做约束，而不希望后面那些层再额外限制约束业务层影响业务层的功能。
在这种思考方式下，如果他是后端代码实现逻辑的，那么它就不希望数据库来存在存储过程，外键，等在后端代码控制范围外的约束来干扰它。
如果是 GraphQL 的那则是希望连后端代码都别做太多约束限制影响它的查询。

@encro 哈哈 是个大坑 一般置 NULL 还没用过别的

@calpes #85 所以我在写 Rails 1.x 2.x 和 3.x 的时候还没有外键。
4.2 已经是个很新的版本了，才出来 5 年。
换句话说，当他是「硅谷创业公司最喜欢的框架」的时候，他还没有外键呢。

@msg7086 别杠啊，rails 04 年才发布，5 年已经是整个生命周期的三分之一了，目前 rails 的应用里 rails4 的占大头，而且 activerecord 很明显的为外键提供了一整套支持，作为同时开发和维护过 3.x 和 4.x 两个版本的 app 的人，你能很明显地感觉到从数据库层面支持外键后对复杂业务带来的开发效率提升，我觉得我这么干说不太好，我建议你试试看，最好能做实际业务的尝试。
至于是不是「硅谷创业公司的最爱」，我也能明确的告诉你，至少在 15，16 年的时候，rails4 是的，但是随着人工智能的兴起，现在应该是 Django 或者 flask 了吧，想想就难受

@calpes Rails 4 / 5 默认都是不会生成 数据库外键约束的， 只有在 migration 文件内指明 add_foreign_key 或 add_reference 指明 foreign_key: true，才会去真正的生成外键约束。

支持不代表推荐

@calpes 所以说这层楼说的是「数据库外键」。你说的 ActiveRecord 里的那些「外键」设计都是业务逻辑上的外键，恰好就是这楼里说的「数据库外键」的对立面。我们从 1.x 写到 5.x，一直都用的是「数据库外键」的反面逻辑外键。

Rails 一直到 4.2 才开始（被迫）支持数据库外键，不就是因为 Rails 的团队和用户都觉得数据库外键不好用吗？如果他们都用的话，为什么这么晚才支持呢。

@msg7086 “Rails 一直到 4.2 才开始（被迫）支持数据库外键，不就是因为 Rails 的团队和用户都觉得数据库外键不好用吗？如果他们都用的话，为什么这么晚才支持呢。” 谁主张谁举证，亮出你的 case

@calpes 还谁主张谁举证，这又不是法院。举证了难道还能打赢官司让你赔钱不成。

我从 Rails 1.x 写到 5.x，我所在的单位我所有的同事从来没有说觉得需要用数据库外键而不是逻辑外键的。Rails 本身就支持逻辑外键，已经能实现外键的功能了，去用数据库外键本就是多此一举。Rails 一直标榜最佳实践，一个从 1.x 到 4.1 都没有支持的基础功能，显然不是最佳实践。换句话说，这个功能从 4.2 才加入支持这件事情，本身就能举证这个功能没有什么需求，也不符合 Rails 心目中的最佳实践。否则你可以问问自己，只是往数据库建表 DDL 里加一个 FOREIGN KEY 指令这么简单的一件事，而且又是数据库存储层这么基础的功能，为什么拖到了 Rails 发布之后的第 9 年才做上。

再反过来说，数据库外键本来就是反 Rails 的。Rails 里对于修改操作是可以挂钩子的，所以如果你 Migration 里给数据表加上了 foreign key constraint 做 cascade，但是又忘记在逻辑层加上逻辑外键做相同的声明的话，数据库会瞒着应用层去修改或者删除数据，跳过所有的逻辑钩子。

再继续说，就算你没忘记，但是你的程序有朝一日改了逻辑，去掉了逻辑外键或者修改了外键约束行为，但是忘了去加 migration 做 ALTER TABLE 把数据库外键改掉或者删掉，那么你马上就会享受到各种喜闻乐见的数据自己失踪的效果。

可能你喜欢这么折腾，我的话还是御免了，小心脏玩不起。

至于 4.2 才加入支持这件事情，是写在 Release notes 里的，这应该不需要「举证」了吧。

如果你真的搞不明白，又或者你完全是无路赛无路赛无路赛状态的话，我也不多说了。同样几句话翻来覆去说很多遍没意思。