关于软件产品表主键设计的疑问：代理键与外键方案探讨

先明确下咱们的场景：应该是一套层级关联的表结构——比如「楼宇表」→「办公室表」→「员工表」这类层级关系对吧？你和同事的分歧点在于后续子表的主键选择：同事想给每张表都用独立的代理键（比如buildingId、officeId、workerId），而你认为子表应该用自身业务键做主键，父表ID当外键。

咱们拆解下两种方案的核心逻辑和适用场景：

同事方案：全表使用独立代理键 #

• 核心逻辑：每张表都用无业务含义的自增/UUID等代理键作为主键，关联时通过外键指向父表的代理键。比如：
  • 楼宇表：buildingId（主键）+ 其他业务字段
  • 办公室表：officeId（主键）+ buildingId（外键）+ 其他业务字段
  • 员工表：workerId（主键）+ officeId（外键）+ 其他业务字段
• 优势：
  • 主键稳定性极强：就算业务字段（比如办公室编号）发生变更，主键不受影响，关联关系不会断裂
  • 表结构扩展灵活：后续如果层级调整（比如新增「楼层表」），不需要修改现有主键结构
  • 性能友好：自增代理键在索引和存储上的性能表现通常更优
• 劣势：
  • 缺少业务语义：主键本身无法直接体现数据的层级关系，排查问题时需要多表关联才能理清归属

你的方案：子表用业务键做主键，父ID为外键 #

• 核心逻辑：子表以自身的业务唯一标识为主键，父表ID作为外键关联。比如：
  • 楼宇表：buildingId（主键）
  • 办公室表：officeId（主键）+ buildingId（外键）
  • 员工表：workerId（主键）+ officeId（外键）
    （这里我猜你的深层逻辑可能是：officeId本身在业务上是唯一的，不需要再额外加代理键？）
• 优势：
  • 主键带业务含义：看到officeId就能直接知道这是哪个办公室的数据，无需关联父表
  • 减少冗余字段：不需要额外维护一个无意义的代理键字段
• 劣势：
  • 主键稳定性弱：如果业务规则变更（比如办公室编号需要重新编排），主键修改会牵一发而动全身，所有关联表的外键都要同步修改，风险极高
  • 扩展性差：如果后续业务要求一个办公室下有多个同编号的工位（虽然概率低，但存在可能性），现有主键结构就会失效，必须重构

折中建议（最常用的工业界方案） #

其实没必要非黑即白，推荐结合两种方案的优点：

• 父表（楼宇表）：用buildingId代理键做主键（如果buildingId是业务唯一键也可以用业务键，但代理键更稳妥）
• 子表（办公室表）：
  • 主键用代理键officeId
  • 同时给buildingId + officeBizCode（办公室的业务编号）加唯一约束，保证业务唯一性
• 员工表同理：
  • 主键用代理键workerId
  • 给officeId + workerBizCode加唯一约束

这样既保证了主键的稳定性和扩展性，又通过唯一约束维护了业务上的唯一性，排查问题时也能通过业务编号快速定位。

另外补充一点：如果你的场景中，officeId是全局唯一且永远不会变更的业务键（比如政府统一分配的办公室编码），那你的方案完全可行；但如果officeId是内部自定的、存在变更可能的编码，那同事的代理键方案风险更低。

内容的提问来源于stack exchange，提问作者Alex Arre