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

[libasten]

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

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

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

[snw]

ERP 系统之类五年十年稳定不变的加（基础字段），各类分析系统整天变动的不加。

[loading]

数据库考试的时候要加

生产环境，在代码里面搞定关系，数据库用事务保证，begin commit

[526326991]

面向项目开发 不用❎
面向模型开发 用✅
底层开发 需要
业务开发 不要

[cutiechi]

开发的时候用，上线全删了

[Rache1]

本来以前都不加的，最近这个项目有，又给加上了，用起来也不错，没那么不堪，主要是用来联动删除数据之类的。

[richarddingcn]

线上业务设计 db 都不考虑 normalization 的 上啥 fk

[agmtopy]

不搞,金融系统都从来不搞,麻烦

[wzw]

如果 PostgreSQL + GORM ，是不是最好的：
在 GORM 配置中开启 DisableForeignKeyConstraintWhenMigrating: true ，抛弃物理外键。

这样?

[oed]

想起电工，老师傅带小师傅，电灯接线要不要关总闸，原则上是需要的......

[abc0123xyz]

不搞，田园敏捷开发搞这个就是作死。