你们现在设计系统数据库的时候还在数据库层面搞外键约束吗？

[libasten]

手里一个项目升级，数据库稍有变动，ai 帮忙的，给加了外键，然后它自己老是迁移升级过不去，外键校验卡住了。
然后我就问了下其他 ai 。
回答有点意思。

## 豆包
可能是互联网短平快开发的代表？主要意见是不要数据库层面搞外键，会给数据库维护带来麻烦，比如之前遇到的外键校验之类的，强烈建议我在业务逻辑中做校验限制啥的。

## qwen
他家是不是金融类工业类的用语料多？和豆包不一样，强烈建议我在数据库层面就加上外键，除非是经常发生上亿级别的数据库变动啥的，会影响效率，否则都建议做外键。

[Mithril]

要么开始就加，要么一直就不加。

从头搞项目的话，看数据类型。数据量预期不会特别大，而且对数据完整性要求比较高的，肯定还是加。其他数据量比较大的东西，比如 xx 记录这种，就尽量搞一张扁平大表，方便后续拆出去，上队列或者缓存，或者 OLAP 等其他的服务。

[mqnu00]

不上，有额外开销

[urlk]

从来没用过外键, 互联网行业需求变化快, 甚至表结构都经常改来改去, 上外键不是自找没事吗

[JoeDH]

从来不用

[whoosy]

从来不用物理外键

[wogogoing]

在业务/代码层面做关联约束。

[woodfizky]

不做。
你正文里这个例子就已经说明外键的问题之一了，遇到数据库迁移或者在现有表上改设计的时候外键要让你头疼死。
性能也不太好。

ORM 可以加虚拟外键。或者你自己写业务查询的时候自己 join 一下就好了。

[opengps]

不做，将来如果有调整会容易一大截，这种调整不光是不合理，也包括业务做大了的分裤分表分布式

[htxy1985]

早在 200x 年都已经定下的策略，从不用。

[justNoBody]

除了最早 oracle 的项目外，从来没加过外键

[yinmin]

不做外键约束，这货会害死运维的

[Plating]

不加，DBA 和公司规范也早就不推荐了

[Felldeadbird]

我不会用，有时候删数据要把其他地方也清掉，很烦。
新项目交给 AI ，AI 很喜欢用。

[iamzcr]

不搞外键约束，没有专业的 DBA,后面维护贼麻烦，直接程序上处理，利用事务。

[realpg]

一般不搞， 偶尔搞， 外键主要用于自动 cascade 清空关联数据 不用其他功能

[LeegoYih]

前阵子和一个玩游戏认识的老外朋友一起开发一个工具，我主导设计表结构和接口，我就按照肌肉记忆理所当然地没有加外键。

结果他看完表结构后问我：不是哥们，你的表之间明明有关联，为什么不定义外键？
我解释说：不加外键写入性能更好，在我们这绝大多数项目都是不加的，加外键的反而才是少数。他表示惊了。

[pulutom40]

这得看你用什么数据库，mysql 外键跟狗屎一样，所以大家都不用。换 pg 会好很多。

过内互联网公司都是用 mysql ，因此大家都不加外键。而海外公司人手 pg ，因此都会按关系型数据库的原本用法来使用

[back0893]

不加 鬼知道产品咋个改 运维?那不是开发自己

[lucays]

肯定不加吧，qwen 有问题

[tianjiyao]

我用 pgsql AI 都是会加外键的啊。。