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

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

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

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


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

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





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

------解决方案--------------------

探讨

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

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

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

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