是什么理由让你彻底抛弃数据库的外键？

[ljk]

初涉后台开发未深，诚惶诚恐看 <SQL 反模式>，学习最佳实践。

发现现在这个项目应用了不少反模式，其中最让我困惑的是，完全不使用外键，涉及到外键的逻辑全部在应用代码里实现。

询问项目负责人，告知不使用数据库外键主要有两原因:

1. 多台服务器不停机升级时，有可能数据库新加入的外键限制导致新程序没办法在旧数据库上跑
2. 运维人员对数据库外键深恶痛绝（举例说唯品会就是这样做的）

听起来只要是分布式的服务器热升级（第一点原因）、或者团队里有运维人员，就应该抛弃数据库外键了。

业界都是这样做的吗？书上说的当真脱离了实际？

谢不吝赐教。

[aias]

一般都是在逻辑里实现的..

[ljk]

@windowsma 见笑啦也不算洁癖，只是觉得数据库里的垃圾数据总得处理吧。

那么按照你说的"指定默认值或者直接报错"，其实最终也是没打算删除这些垃圾数据，只是在读到的时候做一些处理吧？

[windowsma]

@ljk 报错就会有日志，有日志就会有警报，有警报就得去处理。如果频繁出现垃圾数据，肯定是逻辑有问题，不得去优化逻辑么。。。从来不会无缘无故产生垃圾数据。

[HypoChen]

@ljk 写之前先查一下，看场景，或直接报错或者写默认值

[hxd]

SET FOREIGN_KEY_CHECKS=0;

[liprais]

因为 mysql 外键性能垃圾，另外你们所谓的避免 join 也是因为 mysql join 性能垃圾.......

[Zzzzzzzzz]

主要是互联网领域井喷期当时 mysql 3.xx 和 4.0x 时期并不支持外键、子查询、事务、视图。。。。

[jessynt]

Please see this question: http://stackoverflow.com/questions/83147/whats-wrong-with-foreign-keys

[incompatible]

保证约束需要消耗额外的计算资源。应用服务器相对数据库服务器来说更容易水平扩展，因此约束就放在业务逻辑里做了。

[augustG]

当数据达到一个量级需要分表分库时 外键绝对让你欲仙欲死

[Ouyangan]

@SpicyCat 只是不采用数据库的外键 , 一般表关联采用逻辑关联 , 双向就建一张中间表 .列定义两张表的 id. 其实是一样的,只是人为实现了数据库本身提供的功能 , 好处看楼上回帖就好了. 没有谁对谁错 ,工作经验多了自然知道自己该选择哪种方式了,都是看场景.

[Mogugugugu]

通过事务控制吧

[6IbA2bj5ip3tK49j]

@ljk 我学生用 mysql 存的，课程放在 redis 里面。怎么用外键？

[Ouyangan]

@xgfan 你这个需求怎么来的啊 .

[eslizn]

性能开销和维护成本，还不利于扩展

[sunsh217]

大概只有学生才会讨论这种问题。

[sunsh217]

也只有学生才会严格按教科书的做法去设计表吧。 其实教科书上的规范，根本不是业界的做法。 也可能中国的教科书，都是一帮不思进取的老帮瓜写的。

[guoqiao]

刚毕业的时候，我也觉得既然数据库提供了外键，就应该尽量使用它，这样可以让数据库自动保持数据的完整性。
不过后来发现，一旦使用了外键，那么当数据库变得庞大，就没法进行拆分。
比如说在 Django 里，可以支持多个数据库，但是却不支持夸数据库的外键。
这也意味着，如果你计划在将来将数据存放到多个数据库里，就应该一开始避免外键。

[ljk]

@sunsh217 [<SQL 反模式>]( https://book.douban.com/subject/6800774/ )不是教科书，也不是中国人写的。

[ljk]

@ljk 原来评论不支持 markdown 呵