数据库关系设计：创建用户接口应传关联外键ID还是关联字段值？

两种方案没有绝对的好坏，取决于具体业务场景，但绝大多数通用业务场景下，第二种传team_id的方案更优，核心原因如下：

• 性能优势更明显
  第二种方案不需要额外查询team表获取关联id，单关联场景下就能减少一次数据库查询；如果用户表存在大量关联关系（比如同时关联部门、角色、岗位等多个表），每个关联字段都需要先查询对应id的话，会带来数倍的额外查询开销，高并发场景下接口性能差异会非常突出。
• 数据一致性风险更低
  传团队名称的方案天然依赖team.name的唯一性：如果团队名称没有唯一约束，查询可能返回多条匹配记录，无法确定要绑定的团队；就算加了唯一约束，后续业务如果允许修改团队名称，前端传入的旧名称会直接匹配失败。而team.id是表主键，全局唯一且不会随业务变化修改，完全不存在上述问题。
• 开发维护成本更低
  第二种方案逻辑非常简洁，后端拿到参数后直接做外键校验即可执行插入，报错逻辑也很明确：传入的id不存在直接返回参数错误即可。如果用传名称的方案，还要额外处理名称不存在的分支逻辑（是直接报错还是自动创建对应团队？），关联字段多的话每个字段都要写一套查询/异常处理逻辑，代码冗余度会高很多。
• 前后端协作兼容性更好
  对外接口传关联主键是业内通用设计规范：前端渲染团队选择器、团队列表时，本来就会同时拿到id和name两个字段，提交时直接传id是最顺畅的逻辑，不需要额外做名称到id的映射，也不会因为多语言、名称包含特殊字符转义的问题导致匹配失败。

如果你的业务有明确的「创建用户时如果对应团队不存在就自动创建团队」的需求，第一种传名称的方案才是更合适的选择，否则优先选择第二种方案。

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