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

[ljk]

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

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

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

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

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

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

谢不吝赐教。

[duola]

@wind3110991 这是不是所说的 中间表 呢？

[feather12315]

@wind3110991 这是数据库设计的问题，删除异常。并不是外键的锅

[vibbow]

懒

[ifhwhlwpto]

@sunsh217 跟中国的教科书有什么关系，国外的教科书难道就不教你规范？

[beidouxun]

@wind3110991 删除 b 班级肯定把关联此班级学生表的外键清空！等待分配班级！程序的问题！

[q397064399]

@wind3110991 赞

[realpg]

@ljk 合格的程序根本不会出现这种情况
我公司曾开除多次搞出这种问题的程序员

[ebony0319]

我觉得外键大多数存在于教科书。实际项目中比较少（基本上不用）外键，主要是表多了不好维护。用一定的存储过程，一定的视图等。很少在数据库中（至少在我见到的十几万行 sql 中）使用控制流语句。数据库不适合干复杂的事情。

[sunsh217]

@ifhwhlwpto 国外就没有教科书一说

[ren2881971]

因为 drop 的时候太麻烦。。。

[wupher]

除非小项目，基本不使用外键。外键关系使用程序代码来维护，在数据库中不体现。

后期如果需要数据清理，数据调整时，有外键关系（尤其是复杂的外键关系）会造成表数据非常难以修改、维护。

[bi168]

外键确实在实际生产环境中比较少用，一般都在程序中实现逻辑 避免维护修改数据的复杂性

[barbery]

唯品会的确是不允许外键， db 变更如果有外键的话， 99.9%是要被驳回的。。。原因的话，我猜想是互联网企业，性能优先，使用物理外键的话，以后分表分库都会有问题。

[iyangyuan]

逻辑层面统一，物理层面分离，保障以后的可伸缩性

[bi168]

确实一方面给性能带来负担，一方面在交易系统中，删除数据就会自动删除外键数据，这个也会经常出现问题。
关于数据库，数据仓库、大数据、数据分析的问题，我这有个社区 www.bi168.cn 欢迎大家多多交流

[nandaye]

有的主键都不要得，不奇怪，看你的应用场景了

[blacklee]

在 2016 年这个节点，我觉得更早的 2006 年就差不多可以这么说了：

数据库使用外键，属于教条主义！

[fortunezhang]

从来没有用过外键：）

[killerv]

我觉的业务逻辑最好还是写在代码中，外键约束有时候不够灵活，排查问题也不方便

[Balthild]

@sunsh217 有一個英文單詞叫做 textbook