我有客户维度表，客户的位置可以更改。
customerid过滤销售事实表。
我有两个选择：
- 慢慢更改维度类型2，为每个客户的位置更改保留一个新记录
或
- 将数据加载时的位置存储到销售事实表中
这两种方式都允许我按地点查看销售额(尽管这是一个客户地点，但etl会将其放在事实表上(。
后面的选项使我免于在dim表上实现SCD。
决定两种方法中哪一种适合的因素是什么？
如果您想按客户位置查询其他事实，或者确实按位置查询客户，则需要在客户维度中使用它。如果在所有其他情况下，你都不在乎客户的位置过去是什么，你可以避免将客户建模为SCD类型2，如果你在销售时关心客户的位置，就根据事实进行存储。你也可以同时做这两件事…
大多数时候，你会有其他事实在发挥作用，所以最终制定SCD客户维度将是最好的途径。
如何建模位置取决于它与什么相关。如果它是销售的属性，那么它就属于与销售相关的自己的dim。如果它是客户的一个属性(例如他们的家庭地址(，那么它属于客户dim。如果位置是销售和客户的属性，则它属于
事实表应该包含我们测量、计数和合计的内容。你的维度应该是描述性元素，允许用户沿着一个轴分割他们的数据——基本上回答"；通过"；请求的一部分
我想查看这个基于客户的区域层次结构的年度和月度总销售额
不要相信我的话，拿一本数据仓库书或去阅读Kimball Group 免费提供的信息
不管您的数据库引擎如何，根据事实存储客户数据都是个坏主意。为了满足如上所述的查询，存储引擎需要读取整个事实表和支持维度。它可以读取(Date、RegionId、CustomerId、SalesAmount(，无论您有多少行，每行可能花费大约16字节。或者，它可以读取(Date、RegionId、CustomerName、CustomerAddress、CustomerCity、CustomerState、CustomerPostalCode、SalesAmount(，成本为每行70字节？这是的通货膨胀
- 存储数据(磁盘很便宜，但这不是重点(
- 读取数据(基本物理，写入磁盘的数据越多，读取数据所需的时间就越长(
- 其他查询的可用内存较少(您处于多用户/查询环境中，当您占用资源时，其他查询的内存较少(
- 写入数据(ETL处理将花费更长的时间，因为您必须向磁盘写入超出应有数量的页面(
- 无法优化(如果企业只想看到"年度和月度总销售额"-没有客户层次结构，该怎么办？数据库引擎仍然必须读取所有包含无用客户数据的页面，才能获得用户真正想要的东西(
最后，数据仓库工具包中最重要的内容在第1页中。数据仓库项目失败的最大原因是IT驱动了需求，听起来你想这样做是为了避免创建SCD类型2维度。如果您试图解决的业务问题是，他们需要能够在发生时查看与客户数据关联的销售数据，那么您就有了类型2的客户维度。
是的，像Columnstore Compression这样的技术可以减少所需的存储量，但这并不是免费的，因为现在你正在向cpu添加工作负载。也许你有，也许你没有。或者，你对它进行了正确的建模，然后也进行了压缩，你仍然可以在一个合适的维度模型中领先。