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

[maitiantuzi]

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

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

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