leader 竟然让我们用外键

[InkAndBanner]

楼主应届生,第一份工作,之前在 jd 实习时候记得都是严禁外键的,都在业务层解决.前天入职正好赶上 leader 和主程在设计表结构,然后说"我知道现在很多公司都不用外键,但是我觉得我们项目还是用外键,避免脏数据嘛" [leader 是个老程序员...] , 现在显示和我接受到的教育开始冲击了......有点怀疑人生. 想问问大家你们工作中的项目有没有用过外键啊? 怎么处理这种技术方面的"厌恶感"啊

[xuanbg]

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

[fyxtc]

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

[helloworldgo]

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

[php01]

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

[dongeast52123]

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

[youxiachai]

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

[calpes]

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

[calpes]

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

[firesd]

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

[OldHu]

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

[helloworldgo]

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

[ZhiyuanLin]

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

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

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

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

[zpf124]

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


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

[JasperYanky]

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

[msg7086]

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

[calpes]

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

[LinJunzhu]

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

支持不代表推荐

[msg7086]

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

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

[calpes]

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

[msg7086]

@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 里的，这应该不需要「举证」了吧。

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