像用会员号记账：只要号码永远不变、每家门店也不重复，一切都很省事；一旦换号或合并系统，旧订单究竟属于谁，就可能说不清。Reddit 用户 biga410 遇到的正是这个担忧：他从零搭建数据仓库时，直接用源系统键连接维度表与事实表，没有设置代理键——由仓库自行生成、没有业务含义的内部编号。
目前需求似乎允许这样做。他不需要追踪维度的历史变化，SCD Type 1——属性更新时直接覆盖旧值——也够用，甚至不关心客户地址变化。但代理键的价值不只在地址：它能把仓库内部关系与上游编号变更、多套系统键冲突隔开；若以后采用 SCD Type 2，即为每次变化新增带有效期的版本，代理键还能让旧事实继续指向当时的客户或商品版本。
所以问题不是“不用就一定翻车”，而是现在省下的改造，会不会变成未来重写管道的成本。原帖只提出了应立即补齐，还是等需求出现后逐张维度表改造，并未给出实际故障或量化结论。