

























这是一个创建于 83 天前的主题,其中的信息可能已经有所发展或是发生改变。
手里一个项目升级,数据库稍有变动,ai 帮忙的,给加了外键,然后它自己老是迁移升级过不去,外键校验卡住了。
然后我就问了下其他 ai 。
回答有点意思。
## 豆包
可能是互联网短平快开发的代表?主要意见是不要数据库层面搞外键,会给数据库维护带来麻烦,比如之前遇到的外键校验之类的,强烈建议我在业务逻辑中做校验限制啥的。
## qwen
他家是不是金融类工业类的用语料多?和豆包不一样,强烈建议我在数据库层面就加上外键,除非是经常发生上亿级别的数据库变动啥的,会影响效率,否则都建议做外键。
1 Mithril 3 月 23 日要么开始就加,要么一直就不加。 从头搞项目的话,看数据类型。数据量预期不会特别大,而且对数据完整性要求比较高的,肯定还是加。其他数据量比较大的东西,比如 xx 记录这种,就尽量搞一张扁平大表,方便后续拆出去,上队列或者缓存,或者 OLAP 等其他的服务。 |
2 mqnu00 3 月 23 日不上,有额外开销 |
3 urlk 3 月 23 日从来没用过外键, 互联网行业需求变化快, 甚至表结构都经常改来改去, 上外键不是自找没事吗 |
4 JoeDH 3 月 23 日从来不用 |
5 whoosy 3 月 23 日从来不用物理外键 |
7 woodfizky 3 月 23 日不做。 ORM 可以加虚拟外键。或者你自己写业务查询的时候自己 join 一下就好了。 |
8 opengps 3 月 23 日不做,将来如果有调整会容易一大截,这种调整不光是不合理,也包括业务做大了的分裤分表分布式 |
9 htxy1985 3 月 23 日早在 200x 年都已经定下的策略,从不用。 |
10 justNoBody 3 月 23 日除了最早 oracle 的项目外,从来没加过外键 |
11 yinmin 3 月 23 日 via iPhone不做外键约束,这货会害死运维的 |
12 Plating 3 月 23 日不加,DBA 和公司规范也早就不推荐了 |
13 Felldeadbird 3 月 23 日我不会用,有时候删数据要把其他地方也清掉,很烦。 |
14 iamzcr 3 月 23 日不搞外键约束,没有专业的 DBA,后面维护贼麻烦,直接程序上处理,利用事务。 |
15 realpg 3 月 23 日一般不搞, 偶尔搞, 外键主要用于自动 cascade 清空关联数据 不用其他功能 |
16 LeegoYih 3 月 23 日 |
17 pulutom40 3 月 23 日 via iPhone这得看你用什么数据库,mysql 外键跟狗屎一样,所以大家都不用。换 pg 会好很多。 过内互联网公司都是用 mysql ,因此大家都不加外键。而海外公司人手 pg ,因此都会按关系型数据库的原本用法来使用 |
18 back0893 3 月 23 日不加 鬼知道产品咋个改 运维?那不是开发自己 |
19 lucays 3 月 23 日肯定不加吧,qwen 有问题 |
20 tianjiyao 3 月 23 日我用 pgsql AI 都是会加外键的啊。。 |
21 snw 3 月 23 日 via AndroidERP 系统之类五年十年稳定不变的加(基础字段),各类分析系统整天变动的不加。 |
22 loading 3 月 23 日数据库考试的时候要加 生产环境,在代码里面搞定关系,数据库用事务保证,begin commit |
23 526326991 3 月 23 日面向项目开发 不用❎ |
25 Rache1 3 月 23 日本来以前都不加的,最近这个项目有,又给加上了,用起来也不错,没那么不堪,主要是用来联动删除数据之类的。 |
26 richarddingcn 3 月 23 日线上业务设计 db 都不考虑 normalization 的 上啥 fk |
27 agmtopy 3 月 23 日不搞,金融系统都从来不搞,麻烦 |
28 wzw 3 月 23 日如果 PostgreSQL + GORM ,是不是最好的: 这样? |
29 oed 3 月 24 日想起电工,老师傅带小师傅,电灯接线要不要关总闸,原则上是需要的...... |
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。