星型架构关联键选整数还是文本？现有文本键架构需优化吗？

这属于不良实践吗？ #

是的，用客户名称这类文本字段作为事实表与维度表的关联键，属于数据仓库星型架构设计中的不良实践，核心问题包括：

• 存储成本高：文本字段的存储空间远大于数值ID，事实表通常是千万甚至亿级数据量，长期累积会造成大量存储浪费。
• 查询性能差：数据库对数值型字段的索引构建、关联匹配效率远高于文本字段，数据量越大，报表查询的速度差距越显著。
• 数据一致性风险：文本字段极易出现拼写错误、大小写差异（如"JLR"和"jlr"）、品牌别名（如"Mercedes"和"奔驰"）等问题，直接导致关联失效或统计结果失真。
• 扩展性不足：若后续客户品牌更名，需要批量更新事实表中所有相关记录，操作成本极高且容易遗漏数据。

是否建议添加索引列并重构关联逻辑？ #

非常建议，这是规范星型架构设计、解决上述问题的标准方案，具体操作步骤如下：

1. 给维度表添加数值型主键：
   为DimClient新增自增整数类型的ClientID列，并设为主键索引：

   ALTER TABLE DimClient ADD ClientID INT IDENTITY(1,1) PRIMARY KEY;
   

2. 给事实表添加外键并填充数据：
   为FactSales新增ClientID列，通过客户名称匹配关联维度表，填充对应的ID值：

   ALTER TABLE FactSales ADD ClientID INT;
   UPDATE FactSales
   SET ClientID = dc.ClientID
   FROM FactSales fs
   INNER JOIN DimClient dc ON fs.client = dc.[Client Name];
   

3. 添加外键约束保障一致性：
   给FactSales的ClientID列设置外键约束，关联DimClient的主键，防止非法数据插入：

   ALTER TABLE FactSales ADD CONSTRAINT FK_FactSales_ClientID FOREIGN KEY (ClientID) REFERENCES DimClient(ClientID);
   

4. 移除冗余的文本字段：
   验证数据关联完全正确后，删除FactSales中的client文本字段：

   ALTER TABLE FactSales DROP COLUMN client;
   

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