leader 竟然让我们用外键

[InkAndBanner]

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

[InkAndBanner]

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

[binux]

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

[charlie21]

诶居然还整成玄学了？

[InkAndBanner]

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

[calpes]

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

[mikicomo]

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

[ys0290]

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

[parthenon2007]

六字真言送给楼主。

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

[SjwNo1]

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

[xingheng]

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

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

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

[Just1n]

@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. 职场玻璃心需要自己去克服和调节。 （这里玻璃心不是贬义的意思，就是描述一种现象）

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

[tairan2006]

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

[qq976739120]

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

[InkAndBanner]

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

[IMCA1024]

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

[InkAndBanner]

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

[arraysnow]

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

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

[xsm1890]

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

[b821025551b]

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

[arraysnow]

@b821025551b 赞同~