数据仓库中的表（维度表或实事表）主键到底应该使用什么类型？ 自增长int 还是直接用业务主键id

数据仓库中的表（维度表或事实表）主键到底应该使用什么类型？ 自增长int 还是直接用业务主键id？
在很多书籍中都讲到数据仓库的表的主键最好是自增长的int型，理由是当数据量很大的情况下，int比字符型的查询速度要快很多。

但是在实际项目中，真的是使用自增长的int型吗？ 在我理解中，如果使用自增长的int型的话，存在以下问题：

1、当某个维度表需要重新抽取的时候（即删除该维度表所有数据），如果源数据库中少了一条维度记录的话，则在事实表中引用原先该维度记录的key会找不到。


使用自增长的int型作为维度表和事实表的主键的话，还会存在哪些弊端？？

在数据仓库表的主键类型上，你们有什么看法？？




[解决办法]
用代理键还是用用业务上的键这个也不是一定的，也要是考虑多方面因素的
如业务系统比较规范，变动也极小的情况下，而且etl过程中也不会涉及到多系统之间的标准化过程，则直接使用业务键较好
另外，使用代理键也并不是简单的用序列，代理键的规则选不好的话，ETL的转换量都可能会增多不少

[解决办法]

引用:

我的想法是， 
如果考虑到方便简单的话，那我会选择直接用业务键作主键，但是如果需要用到渐变维度，或保留历史更新事实表数据的话，用业务主键就做不到了，只能自建主键。 

但是如果建自增长主键的话，又会有问题，比如说我要重新抽取最近两天的数据，我就先把事实表中的两天内的数据删除，维度表中两天内的新增数据给删除，但是这样也会有问题，当你无法确定这些维度表中新增的数据被哪几个事实表所引用的话，那么删除维度…

同意搂主对渐变维度时，建立无实际业务意义列的作为主键的解决方法，但是还是建议在数据仓库中，即使现在没有渐变情况发生也尽量使用无意义键做为主键，一是查询性能可以得到保证，二是给将来可能会出现的渐变留下更好的扩展性。无意义键列可以是自增，也可以是按某种规则生成。

在SQL2005里你可以在表属性中查看它被哪几个表引用（其他数据库也应该都有这个功能），而事实表（或者雪花型结构中的维度表）记录的外键列值和维度表记录的主键列值，对应是相同的。如果知道了要删除维度表记录的主键了，那么到事实表中（雪花型结构的维度表中）找相对应的记录是很方便的。不知道这是否能解决楼主所说的“无法确定维度表中新增数据被哪几个表引用的的“的问题。

[解决办法]
这个和规划方案有关，如果需求中明确要分析历史变化，那么代理键的时候就是必须的，那么自增长的int/number型就是必须的。如果没这明确需求，或者近期没必要，那么可暂时直接用业务主键。

楼主列举的案例，首先全部重新刷新维的情况，无论是否删除数据，对于整个数据质量体系都是有较大影响，一般不允许随便出现，除非主数据等外因的条件改变。如果一旦出现这样的需求，那么需要一次性对所有相关的事实表进行数据重新刷新，以保证数据质量，同时需要回归测试，代价较大。

查看更多 下一篇