数据库设计：外卖应用单个子类型存公共表还是单独建表？

即使仅有骑手这一个用户子类型，绝大多数场景下优先选择方案2（拆分USERS和DELIVERY_PERSON子表），仅极少数极简场景可以考虑方案1，具体分析如下：

方案2的核心优势（即使仅单个子类型也成立） #

• 数据约束更严谨
  方案1无法做字段级的强制校验：你没法要求「只有骑手身份的用户可以填写driver_license_id、avg_rating等字段，且骑手必须填写这些字段」，很容易出现普通用户误写入骑手字段、骑手漏填专属字段的脏数据。方案2天然解决这个问题：只有骑手会在DELIVERY_PERSON表生成记录，该表的所有专属字段都可以加非空等约束，完全避免脏数据。
• 存储和查询效率更高
  你的场景里99%的用户都是普通用户，方案1中每一条用户记录都要预留骑手字段的存储空间，百万级以上用户量会浪费非常可观的存储资源，同时普通用户相关的查询也会因为表结构冗余变慢。方案2的USERS表结构极其精简，普通用户查询完全不需要关联子表，仅骑手相关的业务才需要做关联查询，整体性能表现更好。
• 扩展性更强
  当前你只有骑手一个子类型，但后续业务迭代大概率会新增商家、平台运营等其他用户角色，方案1后续需要不断新增大量不同角色的专属字段，USERS表会变得非常臃肿，大量空值字段的维护成本极高。方案2后续只需要新增对应角色的子表即可，完全不影响原有表结构的稳定性。

仅这种场景可以考虑方案1 #

如果同时满足以下所有条件，可以选择方案1减少开发时的关联查询成本：

• 骑手专属字段仅1-2个，且后续完全不会新增骑手相关字段
• 明确未来不会新增其他用户子类型
• 用户规模极小，存储和性能损耗完全可以忽略

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