大家在正式的环境里面会使用外键么

[yeyuexia]

最近和几个同事聊及对 mysql 的使用的时候，纷纷对我们项目并不使用外键而在逻辑上维护 table 之间的关系这种事情感到不可思议，说“怎么能这么做呢，为什么不用外键？” 这件事情简直对我产生了巨大的冲击，难道还有人会在生产环境上使用外键么？ 如果是的话，能否告诉我为什么要这么做，好处有哪些？ 谢谢

[wshcdr]

我不用，我是用代码来维护外键关系

[mikan]

表结构由 hibernate 维护，自带外键

[clinkzlol]

如果使用 ORM 框架来处理数据层，基本上就没外键什么事了

[dong3580]

以前经常用，现在不用了。校验在程序里。

[kafka0102]

不要用框架的实现来规避问题。外键是对数据一致性的约束，使用代码逻辑约束是通常的做法，个人也赞成这种做法。数据库能做很多事情，外键、触发器、存储过程等等，如果你愿意，可以把逻辑都写到数据库端，但这对数据库的维护会带来很多麻烦。如果你是使用 mongodb 等，那你也只能写到代码里。但另一方面，代码逻辑写得再好，也可能造成数据不一致的。所以，如果数据一致性很重要，那么数据库做约束可能是更好的选择。

[yeyuexia]

@clinkzlol
@mikan
使用框架和使用外键是两回事吧？

[pythoner]

我的经验是，在项目初期，为了快速完成功能开发，还是会按照规范添加外键。
随着业务的发展，很多时候，我们需要按照业务功能来做垂直拆分，这个时候就必须得去掉一些外键，以及相关的 join 查询

[asj]

我做过几年的银行业软件，就我见到的系统确实很多生产环境中是不用外键的。原因和正式代码中是否使用断言类似。理论上来说，这些约束有助于维护系统的一致性。但是问题在于，不一致了，又怎么样呢？

在理想世界里，不论数据，代码还是输入输出都是有条有理的。而现实中却常常要面对历史遗留代码和数据，低质量的输入，以及变化无常的输出等等不那么有条理的情况。那么，比如一个系统运行到某个点时，发现某项检查与预期不一致的时候。停止整个系统真的是最好的选择么？又或者输入数据的时候某个字段不一致，因而拒绝整条数据真的是最合理的么？

另一个问题是不方便，当需要批量表数据，调整表结构或者更改程序逻辑的时候，这些约束经常会对开发人员造成困扰。虽然一般来说各种数据库都有暂时关闭约束的机制，但是确实把问题复杂化了。
而且，不同于 UI 上对随机的普通用户操作的校验，或者系统对恶意攻击者的安全性检查，数据库外键这类约束阻止掉的操作，来自于系统的开发和维护人员。一般来说他们最了解系统的内部结构，很清楚自己在做什么，对系统的一切有着最高的权限。这时候他们更容易觉得这种约束烦人而不是可靠。

[felixzhu]

外键相对来说还是可以用的，这种强一致性的约束通过代码是有可能出问题的
主要问题感觉是后面分库分表的时候比较麻烦吧

[SmiteChow]

如果没有强理由，外健是物理和逻辑上最好的选择，上面说到的数据历史问题，说明技术选型不是很对，参看 Django Migration 。

[zyAndroid]

没有外键的话代码得写成什么样子，无法想象。

[jhaohai]

数据库里少用这些东西，太耗性能

[jsjscool]

WEB 开发的瓶颈多半在 IO ，需要权衡。没有哪个一定好或者一定不好。

[g67261831]

@asj 赞同。

[JamesRuan]

用外键不需要理由，不用外键才需要找理由。

[slayerdoomsday]

我们 CTO 说，一不要用外键，二不要用 join ，把需要的数据都查出来再用程序处理

[JamesRuan]

@slayerdoomsday 那还要用数据库干嘛，直接自己写入文件好了。

[xuwenhao]

@JamesRuan 如果你要让数据库可以水平拆库扩展只能选择这么做

[Infernalzero]

@JamesRuan
上面已经有人说了， web 主要瓶颈在数据库，互联网模式一般都是只让数据库做最简单的储存，不做复杂查询，复杂的事交给 web 服务器做， web 服务器的数量是可以不断加的，而 master db 对于某个用户来说是唯一的，不可分割的，而且现在服务器的性能一般的计算根本不算什么

[bravecarrot]

涨姿势了。一直以为都用外键的！