数据建模：将多源ID存储在同一列是否为不良实践？

把不同类型的ID直接存入同一列，是妥妥的不良实践，绝对不推荐。你想到的分类型单独建列的方案比混存好很多，但也不是长期最优解，下面给你拆解下不同方案的问题和更合理的设计思路。

这种设计看起来省事儿，后期维护全是雷：

• 完全失去数据校验能力：你没法在数据库层对ID格式做约束，不管是格式错误的GUID、拼错的Salesforce ID，甚至是乱码、空值都能随便写进这列，等发现数据对不上的时候，脏数据已经攒了一大堆，清洗成本极高。
• 查询关联逻辑极度混乱：后续你要关联人员维度表、做数据统计的时候，根本没法直接写关联条件，必须套一堆CASE WHEN先判断当前行ID属于哪个类型，再去对应来源的表匹配，不仅SQL写得冗余难看，查询性能差，还很容易漏判断条件导致数据算错。
• 语义完全不透明：任何新接触这个表的开发、分析师，看到SalesPersonID列第一反应都是这是统一的人员ID，根本不知道里面混了多种格式，每次用都得翻陈年文档、找老员工确认，沟通成本极高。

你考虑的「每个ID类型建一列，不适用就留空」的方案，确实解决了同列混存的语义模糊、校验困难的问题，但也有明显的短板：

• 扩展性差：如果你后续要接入新的数据源，比如飞书账号ID、旧ERP系统的人员ID、客户管理系统的ID，就得不停给表加新列，不仅要反复改表结构，上下游的ETL任务、报表逻辑、接口代码都得跟着改，非常折腾。
• 空值冗余多：如果大部分人员只来自1-2个数据源，剩下的ID列全是空值，存储浪费倒是小事，你还很难加约束保证「每行至少有一个有效ID」，容易出现两个ID列都为空的无效数据。

如果你的业务非常稳定，确定未来最多只会接入2-3种ID类型，不会再有新数据源，这个方案是够用的，实现成本很低。

更推荐你把内部主键和外部ID做解耦，从根本上避开这些问题，设计分两步：

1. 给你系统内的销售人员生成完全独立的内部全局主键，可以用自增整数或者UUID都行，这个ID只在你自己的系统里用，和所有外部数据源的ID规则完全无关，永远稳定不会变，所有业务表关联人员维度的时候，都用这个内部主键。
2. 单独建一张「外部ID映射表」，专门存不同来源的ID和内部主键的对应关系，表结构参考：

   字段名	字段说明	约束规则
   internal_salesperson_id	内部人员主键	和人员主表做外键关联
   id_type	ID类型	用枚举值固定可选范围，比如guid、salesforce_id、wecom_id
   external_id	对应类型的外部ID值	字符串类型，和id_type做联合唯一约束，保证同类型下ID不会重复

举个例子，同一个内部ID为SP001的销售，在映射表里会存两条记录：一条id_type为guid，对应他的GUID值；另一条id_type为salesforce_id，对应他的Salesforce ID。

这个设计的好处非常明显：

• 扩展性极强：后续接入新的数据源ID，不需要改任何现有表结构，只要给id_type加个新的枚举值，往映射表插对应的数据就行。
• 数据一致性好做：你可以针对不同id_type给external_id加格式校验，通过外键、联合唯一约束从数据库层避免脏数据，不会出现无效ID、重复ID的问题。
• 关联逻辑简单：不管哪个来源的数据进来，只要拿「外部ID+ID类型」去映射表查到对应的内部主键，后续所有关联计算全用内部主键就行，逻辑清晰不容易出错，也不会有大量空值冗余。

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