1
Mithril 14 小时 21 分钟前
要么开始就加,要么一直就不加。
从头搞项目的话,看数据类型。数据量预期不会特别大,而且对数据完整性要求比较高的,肯定还是加。其他数据量比较大的东西,比如 xx 记录这种,就尽量搞一张扁平大表,方便后续拆出去,上队列或者缓存,或者 OLAP 等其他的服务。 |
2
mqnu00 14 小时 14 分钟前
不上,有额外开销
|
3
urlk 14 小时 13 分钟前
从来没用过外键, 互联网行业需求变化快, 甚至表结构都经常改来改去, 上外键不是自找没事吗
|
4
JoeDH 14 小时 4 分钟前
从来不用
|
5
whoosy 14 小时 0 分钟前
从来不用物理外键
|
6
wogogoing PRO 在业务/代码层面做关联约束。
|
7
woodfizky 13 小时 37 分钟前
不做。
你正文里这个例子就已经说明外键的问题之一了,遇到数据库迁移或者在现有表上改设计的时候外键要让你头疼死。 性能也不太好。 ORM 可以加虚拟外键。或者你自己写业务查询的时候自己 join 一下就好了。 |
8
opengps 13 小时 36 分钟前
不做,将来如果有调整会容易一大截,这种调整不光是不合理,也包括业务做大了的分裤分表分布式
|
9
htxy1985 13 小时 32 分钟前
早在 200x 年都已经定下的策略,从不用。
|
10
justNoBody 13 小时 30 分钟前
除了最早 oracle 的项目外,从来没加过外键
|
11
yinmin 13 小时 29 分钟前 via iPhone
不做外键约束,这货会害死运维的
|
12
Plating 13 小时 25 分钟前
不加,DBA 和公司规范也早就不推荐了
|
13
Felldeadbird 13 小时 14 分钟前
我不会用,有时候删数据要把其他地方也清掉,很烦。
新项目交给 AI ,AI 很喜欢用。 |
14
iamzcr 12 小时 20 分钟前
不搞外键约束,没有专业的 DBA,后面维护贼麻烦,直接程序上处理,利用事务。
|
15
realpg PRO 一般不搞, 偶尔搞, 外键主要用于自动 cascade 清空关联数据 不用其他功能
|
16
LeegoYih 11 小时 23 分钟前
|
17
pulutom40 11 小时 0 分钟前 via iPhone
这得看你用什么数据库,mysql 外键跟狗屎一样,所以大家都不用。换 pg 会好很多。
过内互联网公司都是用 mysql ,因此大家都不加外键。而海外公司人手 pg ,因此都会按关系型数据库的原本用法来使用 |
18
back0893 10 小时 49 分钟前
不加 鬼知道产品咋个改 运维?那不是开发自己
|
19
lucays 10 小时 47 分钟前
肯定不加吧,qwen 有问题
|
20
noway5566 10 小时 47 分钟前
我用 pgsql AI 都是会加外键的啊。。
|
21
snw 10 小时 36 分钟前 via Android
ERP 系统之类五年十年稳定不变的加(基础字段),各类分析系统整天变动的不加。
|
22
loading 10 小时 33 分钟前
数据库考试的时候要加
生产环境,在代码里面搞定关系,数据库用事务保证,begin commit |
23
526326991 10 小时 32 分钟前
面向项目开发 不用❎
面向模型开发 用✅ 底层开发 需要 业务开发 不要 |
24
superchijinpeng 10 小时 31 分钟前
开发的时候用,上线全删了
|
25
Rache1 10 小时 21 分钟前
本来以前都不加的,最近这个项目有,又给加上了,用起来也不错,没那么不堪,主要是用来联动删除数据之类的。
|
26
richarddingcn 7 小时 52 分钟前
线上业务设计 db 都不考虑 normalization 的 上啥 fk
|
27
agmtopy 4 小时 44 分钟前
不搞,金融系统都从来不搞,麻烦
|
28
wzw 4 小时 34 分钟前
如果 PostgreSQL + GORM ,是不是最好的:
在 GORM 配置中开启 DisableForeignKeyConstraintWhenMigrating: true ,抛弃物理外键。 这样? |