数据库设计时，主表中有唯一业务编码字段，关联表还需要设计外键吗

[maitiantuzi]

举个例子， 主表 - 物料表 material: id: 主键 ID code: 物料唯一编码 name: 物料名称

物料入库记录表： stock_in: id: 主键 ID material_id: 外键 - 物料 ID （这里需要吗？） mateiral_code: 物料唯一编码 in_date: 入库时间

[abcdexx]

我是很少用数据库的外键，中间表有字段关联就可以了吧。

[forgottencoast]

为了方便你只查物料 ID 的入库记录时不用连表查，间接在这个场景下提高性能，如果没有这需要可以不要。

[yuyuf]

主键 id 是数据库层面的唯一字段，物料唯一编码是业务层面的唯一字段。
看你们是用哪个字段做关联的
拿不准的情况，都存着，冗余一点总比后期加强

[JYii]

外键比较少用了，做删除时有点麻烦，如果有 db 迁移也麻烦

[charmToby]

早就不用物理外键了，都是逻辑外键。

[themostlazyman]

"物料 ID" 逻辑外键也不需要，联表查的话，主表设置"物料唯一编码"唯一约束、唯一索引即可。

[tomatocici2333]

别用物理外键 大坑

[sss15]

实际生产中严格按照第三范式设计的数据库比较少
生产上我觉得唯一索引还是非常非常有必要的，靠代码层面无法杜绝脏数据进去，还是得靠唯一索引

[yuyuf]

楼上说不用物理外键的，这还是要看具体情况。
一些项目并发不高，数据量不大，但对数据准确性要求高，还是能用外键的。
一般大部分互联网公司不用外键
看楼主的描述，可能是一些工业项目呢

[nothingistrue]

实体关联，不管你是数据库层面的物理外键，还是程序层面的逻辑外键，都要用物理主键，否则你也没必要再在自然键之外设计一个代理主键。

对于你的 stock_in 来说，用 material_id 做关联键，才能发挥代理主键的性能。mateiral_code 也有用，但它更多的是作为 stock_in 自身的属性来用。

[jucelin]

material_id 才是主键，mateiral_code 在入库记录中只是为了查询冗余。

mateiral_code 是业务层面的唯一，说不定哪天就 变成 mateiral_code+xxx 是唯一的了。

[bugmaker1024]

逻辑外键+1

[liaojl]

楼上有人提到了，要看具体业务，据我所了解到的，互联网公司很多都是不用物理外键的，但金融行业，比如我目前就职的某个外资银行，就有很多地方会用到，物理外键能在数据库层面保证数据的一致性，逻辑外键的话，代码要是有 bug ，导致的数据问题，要修复的话很麻烦。

[dif]

印象中外键已经是学生阶段老师讲的了，毕业工作这么多年，还真很少见到外键。

[adoal]

如果数据错了只要赔几个站内积分甚至只要道歉甚至连道歉都不用就能吧用户糊弄过去，那啥都不用搞。

如果是要真金白银赔钱，通报批评，记过处分，甚至可能坐牢，还是好好设计一下数据库，各种约束加上去。

[chendy]

具体情况具体分析，好处大于坏处就上，反过来就不上
比如说：
1. 加外键是否会对性能产生重大影响
2. 不加外键，系统逻辑是否足够完善避免脏数据产生
等等…

[xuanbg]

没必要有外键，但外键也不是什么大坑，相关言论有点过于耸人听闻了。

[wushigejiajia01]

mateiral_code: 物料唯一编码
能保证唯一，那物料 ID ，就没必要了啊，
过度冗余数据也不是个好习惯

[totoro52]

大学生才用数据库外键

[IvanLi127]

只要你的数据库只有你的程序能写，并且你的程序能可靠地约束写入的数据的正确性，多步操作失败时能有效回滚，数据库可以不加外键。这个就看实力了。。如果项目不大也不用考虑后续运维菜鸡的问题，所以我建议数据库顶得住，加个外键约束挺好的。

[tietou]

一般是逻辑外键吧

[go522000]

加上去呗，占用不了多少空间，而且又不影响性能。

[i8086]

不考虑物理外键还是逻辑外键。物料 ID 是数据库表主键，性能是第一的。

[SilenceLL]

现在很少有用外键的，性能受限

[forschers]

好像没有咋用外键

[lovelylain]

不用外键，而且你这个场景，一般给物料表的物料唯一编码加上唯一索引，其他表也直接用这个编码而不是引用物料表的主键 ID 。

[kkwa56188]

外键是在数据库层面保证数据的完整准确, 按照数据库的设计规范来说 最好能加,
不加的话, 实际业务 要是能承受 出问题时候的情况, 也可以.

我举三个例子, 按照数据出错的严重程度从轻到重 :
1. 在商品评价表里 出现有一条评分来自未知用户, 不存在于用户主表里
2. 在入库表里 发现 有一个 未知的物料, 不存在于物料主表里.
3. 在 支出费用表里出现一张未知的发票, 不存在于发票主表里

[pheyx]

@adoal 你个干图书馆的破 it 懂个屁

[akira]

有 mateiral_code 做唯一索引就够了，另外你的 id 大概率是 自增 id ，不建议参与业务

[ChadGPT]

自增 id 如果参与业务，未来不同类型数据库迁移的时候可能会有麻烦

[dyv9]

@jucelin 同一个型号的零件也有多个供应商呢。所以眼看到的编号不一定能用作唯一键。

[dyv9]

@JYii 麻烦是好事，正好阻止了一步破坏所有数据的能力，构造数据和修改数据都要理解数据否则操作不下去。我见过给数据打补丁的人不完全理解设计，直接把一批数据改一样的了。