星型模式中副表用同一列兼作PK与FK是否为良好实践？

这是个很实际的设计问题，尤其在星型数据仓库的场景下，咱们来拆解这种做法的优劣，帮你判断是否适配你的业务需求：

这种做法的优势 #

• 简化关联逻辑：主副表共享ApsilankymoID作为关联键，编写查询SQL时无需处理额外的独立ID字段，语句更简洁直观，比如：

  SELECT a.*, d.* 
  FROM Apsilankymas a 
  LEFT JOIN ApsilankymoDetaliai d ON a.ApsilankymoID = d.ApsilankymoID
  

• 节省存储开销：不需要为副表额外维护独立主键（比如自增ID），减少了冗余字段的存储，对于数据量较大的仓库来说，长期能降低存储成本。
• 天然保障1:0..1关系：副表的主键直接引用主表主键，从结构上就限制了每条主表记录最多对应一条副表记录，完美匹配你提到的关联需求，无需额外添加唯一约束。

潜在的局限性 #

• 扩展性不足：如果未来业务需求变化，需要将1:0..1关系调整为1:N（比如一条主表记录对应多条副表记录），这种设计会直接失效，必须重构表结构，成本较高。
• 语义易混淆：ApsilankymoID同时承担主键和外键的角色，对于后续维护的开发人员（尤其是不熟悉星型模式的成员），需要额外时间理解字段的双重作用，可能增加认知成本。
• 范式层面的争议：虽然数据仓库通常允许反范式设计，但严格遵循第三范式的OLTP开发者可能会觉得这种设计“不规范”——不过这一点在数据仓库场景下的优先级较低，仓库更侧重查询效率而非写入灵活性。

结论 #

如果你的业务需求长期稳定，确定不会改变1:0..1的关联关系，且更看重查询简洁性和存储效率，那么这种做法是完全可行的，甚至是星型模式中常见的优化手段。但如果存在业务扩展的可能性，或者团队更倾向于通用的设计规范，那么给副表设置独立主键，再将ApsilankymoID作为外键并添加唯一约束，会是更稳妥的选择。

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