7,388
社区成员
发帖
与我相关
我的任务
分享数据仓库中的表（维度表或事实表）主键到底应该使用什么类型？ 自增长int 还是直接用业务主键id？
在很多书籍中都讲到数据仓库的表的主键最好是自增长的int型，理由是当数据量很大的情况下，int比字符型的查询速度要快很多。
但是在实际项目中，真的是使用自增长的int型吗？ 在我理解中，如果使用自增长的int型的话，存在以下问题：
1、当某个维度表需要重新抽取的时候（即删除该维度表所有数据），如果源数据库中少了一条维度记录的话，则在事实表中引用原先该维度记录的key会找不到。
使用自增长的int型作为维度表和事实表的主键的话，还会存在哪些弊端？？
在数据仓库表的主键类型上，你们有什么看法？？
但是在实际项目中，真的是使用自增长的int型吗？ 在我理解中，如果使用自增长的int型的话，存在以下问题：
1、当某个维度表需要重新抽取的时候（即删除该维度表所有数据），如果源数据库中少了一条维度记录的话，则在事实表中引用原先该维度记录的key会找不到。
使用自增长的int型作为维度表和事实表的主键的话，还会存在哪些弊端？？
在数据仓库表的主键类型上，你们有什么看法？？
...全文
请发表友善的回复…
发表回复
qixuzhen 2012-05-03
- 打赏
- 举报
[Quote=引用楼主 的回复:]
在很多书籍中都讲到数据仓库的表的主键最好是自增长的int型，理由是当数据量很大的情况下，int比字符型的查询速度要快很多。
但是在实际项目中，真的是使用自增长的int型吗？ 在我理解中，如果使用自增长的int型的话，存在以下问题：
1、当某个维度表需要重新抽取的时候（即删除该维度表所有数据），如果源数据库中少了一条维度记录的话，则在事实表中引用原先该维度记录的key会找不到。
……
[/Quote]
这个时候可以把一些的记录的key回插到维度表中吧。这样就能跟事实表关联了。只不过那个key的其他信息是null。如果知道了其他的信息，可以直接更新维度表，就好了。
在很多书籍中都讲到数据仓库的表的主键最好是自增长的int型，理由是当数据量很大的情况下，int比字符型的查询速度要快很多。
但是在实际项目中，真的是使用自增长的int型吗？ 在我理解中，如果使用自增长的int型的话，存在以下问题：
1、当某个维度表需要重新抽取的时候（即删除该维度表所有数据），如果源数据库中少了一条维度记录的话，则在事实表中引用原先该维度记录的key会找不到。
……
[/Quote]
这个时候可以把一些的记录的key回插到维度表中吧。这样就能跟事实表关联了。只不过那个key的其他信息是null。如果知道了其他的信息，可以直接更新维度表，就好了。
zuocl 2010-01-27
- 打赏
- 举报
[Quote=引用楼主 jackyxu_2008 的回复:]
在很多书籍中都讲到数据仓库的表的主键最好是自增长的int型，理由是当数据量很大的情况下，int比字符型的查询速度要快很多。
但是在实际项目中，真的是使用自增长的int型吗？ 在我理解中，如果使用自增长的int型的话，存在以下问题：
1、当某个维度表需要重新抽取的时候（即删除该维度表所有数据），如果源数据库中少了一条维度记录的话，则在事实表中引用原先该维度记录的key会找不到。
使用自增长的int型作为维度表和事实表的主键的话，还会存在哪些弊端？？
在数据仓库表的主键类型上，你们有什么看法？？
[/Quote]
我觉得如果连维度表也要重新抽取的话，那么事实表肯定也要重新抽取
在很多书籍中都讲到数据仓库的表的主键最好是自增长的int型，理由是当数据量很大的情况下，int比字符型的查询速度要快很多。
但是在实际项目中，真的是使用自增长的int型吗？ 在我理解中，如果使用自增长的int型的话，存在以下问题：
1、当某个维度表需要重新抽取的时候（即删除该维度表所有数据），如果源数据库中少了一条维度记录的话，则在事实表中引用原先该维度记录的key会找不到。
使用自增长的int型作为维度表和事实表的主键的话，还会存在哪些弊端？？
在数据仓库表的主键类型上，你们有什么看法？？
[/Quote]
我觉得如果连维度表也要重新抽取的话，那么事实表肯定也要重新抽取
highroad 2009-04-12
- 打赏
- 举报
另外一个想法是在数据仓库中的维表中保留一个业务系统中的UUID字段，这样维度变化时可以对应更新，事实表转化时，可以参照找到数字型的数据仓库主键，毕竟维表的数据量不会太大，而事实表的数据量是很大的，事实表外键用UUID，数据仓库增长会快，且查询效率不高
highroad 2009-04-12
- 打赏
- 举报
关注，这也是我现在处理时遇到的问题。
原来的业务系统，是生成的UUID，如果提取到数据仓库转换成数字类型的话，要另外写比较复杂的过程。
原来的业务系统，是生成的UUID，如果提取到数据仓库转换成数字类型的话，要另外写比较复杂的过程。
jackyxu_2008 2009-03-26
- 打赏
- 举报
本来想多了解一下更多人的观点，可是参与的人不多，就先这样结贴吧，感谢楼上答复的几位朋友
jackyxu_2008 2009-03-24
- 打赏
- 举报
统一楼上的看法，数据仓库中的数据是保存历史数据的，理论上来说是不允许修改的，但是有时也会出现特殊情况的出现，只有当特殊情况发生的时候，才会需要重新抽取故障期间的这几天数据，所以设计时也是需要考虑到这种情况的
DWSTAR 2009-03-24
- 打赏
- 举报
总结的不错！
innovate911 2009-03-23
- 打赏
- 举报
这个和规划方案有关，如果需求中明确要分析历史变化，那么代理键的时候就是必须的，那么自增长的int/number型就是必须的。如果没这明确需求，或者近期没必要，那么可暂时直接用业务主键。
楼主列举的案例，首先全部重新刷新维的情况，无论是否删除数据，对于整个数据质量体系都是有较大影响，一般不允许随便出现，除非主数据等外因的条件改变。如果一旦出现这样的需求，那么需要一次性对所有相关的事实表进行数据重新刷新，以保证数据质量，同时需要回归测试，代价较大。
楼主列举的案例，首先全部重新刷新维的情况，无论是否删除数据，对于整个数据质量体系都是有较大影响，一般不允许随便出现，除非主数据等外因的条件改变。如果一旦出现这样的需求，那么需要一次性对所有相关的事实表进行数据重新刷新，以保证数据质量，同时需要回归测试，代价较大。
jackyxu_2008 2009-03-21
- 打赏
- 举报
[Quote=引用 5 楼 lpc19598188 的回复:]
int比varchar2又能快多少？差别很小吧
[/Quote]
大数据量的数据仓库是可以看出效果来的
int比varchar2又能快多少？差别很小吧
[/Quote]
大数据量的数据仓库是可以看出效果来的
jackyxu_2008 2009-03-21
- 打赏
- 举报
我觉得重新抽取比较麻烦，需要判断数据仓库中所有表，如果该数据仓库很大，就相当麻烦。不知道有什么好的建议？
还有如果这样一条记录，该记录在前天被修改过一次，昨天又被修改过一次，现如果需要重新抽取这两天的历史数据，则会把抽取开始时间定为前天的0点，那么在前天修改过的那条修改记录的动作将不会被保存进数据库，这样就会造成漏掉数据， 这一点又该如何避免？？
还有如果这样一条记录，该记录在前天被修改过一次，昨天又被修改过一次，现如果需要重新抽取这两天的历史数据，则会把抽取开始时间定为前天的0点，那么在前天修改过的那条修改记录的动作将不会被保存进数据库，这样就会造成漏掉数据， 这一点又该如何避免？？
DWSTAR 2009-03-21
- 打赏
- 举报
如果数据仓库系统数据不很大，全部抽取是可以的，但如果数据量非常大，那全量抽取就不可取了。
重新抽取一般很少用，一般是系统在抽取时出现宕机等灾难性问题时可能会对以前的抽取工作再重新处理一次。尽量减少不必要的删除重新抽取操作。
数据仓库数据是用来分析的状态一般是稳定的，尽量不对数据仓库做删除操作。即使要做删除操作也有两种方式可以选择：一种是物理删除，就是楼主说的那种直接从表中删掉。另一种是逻辑删除，即数据还在数据库表中，但该表有一列用作标记该纪录是否处于“已删除”状态。这样用户有了新的需求变更也能挽回原来的数据记录。
数据仓库毕竟是做分析用的，对数据的删除偶尔一次是可以的，数据仓库管理员应该有这个权力。但应尽量杜绝决频繁删除操作。尤其是用户的删除操作更应避免。不然你改一次我改一次分析就乱套了。具体情况和用户协调清楚，充分分析他们的需求。制定合适的数据加载机制！
DWSTAR 2009-03-21
- 打赏
- 举报
[Quote=引用 4 楼 jackyxu_2008 的回复:]
我的想法是，
如果考虑到方便简单的话，那我会选择直接用业务键作主键，但是如果需要用到渐变维度，或保留历史更新事实表数据的话，用业务主键就做不到了，只能自建主键。
但是如果建自增长主键的话，又会有问题，比如说我要重新抽取最近两天的数据，我就先把事实表中的两天内的数据删除，维度表中两天内的新增数据给删除，但是这样也会有问题，当你无法确定这些维度表中新增的数据被哪几个事实表所引用的话，那么删除维度…
[/Quote]
同意搂主对渐变维度时，建立无实际业务意义列的作为主键的解决方法，但是还是建议在数据仓库中，即使现在没有渐变情况发生也尽量使用无意义键做为主键，一是查询性能可以得到保证，二是给将来可能会出现的渐变留下更好的扩展性。无意义键列可以是自增，也可以是按某种规则生成。
在SQL2005里你可以在表属性中查看它被哪几个表引用（其他数据库也应该都有这个功能），而事实表（或者雪花型结构中的维度表）记录的外键列值和维度表记录的主键列值，对应是相同的。如果知道了要删除维度表记录的主键了，那么到事实表中（雪花型结构的维度表中）找相对应的记录是很方便的。不知道这是否能解决楼主所说的“无法确定维度表中新增数据被哪几个表引用的的“的问题。
我的想法是，
如果考虑到方便简单的话，那我会选择直接用业务键作主键，但是如果需要用到渐变维度，或保留历史更新事实表数据的话，用业务主键就做不到了，只能自建主键。
但是如果建自增长主键的话，又会有问题，比如说我要重新抽取最近两天的数据，我就先把事实表中的两天内的数据删除，维度表中两天内的新增数据给删除，但是这样也会有问题，当你无法确定这些维度表中新增的数据被哪几个事实表所引用的话，那么删除维度…
[/Quote]
同意搂主对渐变维度时，建立无实际业务意义列的作为主键的解决方法，但是还是建议在数据仓库中，即使现在没有渐变情况发生也尽量使用无意义键做为主键，一是查询性能可以得到保证，二是给将来可能会出现的渐变留下更好的扩展性。无意义键列可以是自增，也可以是按某种规则生成。
在SQL2005里你可以在表属性中查看它被哪几个表引用（其他数据库也应该都有这个功能），而事实表（或者雪花型结构中的维度表）记录的外键列值和维度表记录的主键列值，对应是相同的。如果知道了要删除维度表记录的主键了，那么到事实表中（雪花型结构的维度表中）找相对应的记录是很方便的。不知道这是否能解决楼主所说的“无法确定维度表中新增数据被哪几个表引用的的“的问题。
又是违规昵称 2009-03-20
- 打赏
- 举报
int比varchar2又能快多少？差别很小吧
jackyxu_2008 2009-03-20
- 打赏
- 举报
我的想法是，
如果考虑到方便简单的话，那我会选择直接用业务键作主键，但是如果需要用到渐变维度，或保留历史更新事实表数据的话，用业务主键就做不到了，只能自建主键。
但是如果建自增长主键的话，又会有问题，比如说我要重新抽取最近两天的数据，我就先把事实表中的两天内的数据删除，维度表中两天内的新增数据给删除，但是这样也会有问题，当你无法确定这些维度表中新增的数据被哪几个事实表所引用的话，那么删除维度表后，这些事实表中所引用那些已删除的维度外键的记录就会无法匹配。
如何来解决这个问题呢？？？ 有没有比较好的项目实施经验？？？
如果考虑到方便简单的话，那我会选择直接用业务键作主键，但是如果需要用到渐变维度，或保留历史更新事实表数据的话，用业务主键就做不到了，只能自建主键。
但是如果建自增长主键的话，又会有问题，比如说我要重新抽取最近两天的数据，我就先把事实表中的两天内的数据删除，维度表中两天内的新增数据给删除，但是这样也会有问题，当你无法确定这些维度表中新增的数据被哪几个事实表所引用的话，那么删除维度表后，这些事实表中所引用那些已删除的维度外键的记录就会无法匹配。
如何来解决这个问题呢？？？ 有没有比较好的项目实施经验？？？
jackyxu_2008 2009-03-20
- 打赏
- 举报
没人顶啊，只好自己顶
SOS
SOS
jackyxu_2008 2009-03-20
- 打赏
- 举报
upup
请各位TX积极讨论自己的观点，谢谢
我一定会给分的
请各位TX积极讨论自己的观点，谢谢
我一定会给分的
zmgowin 2009-03-20
- 打赏
- 举报
用代理键还是用用业务上的键这个也不是一定的，也要是考虑多方面因素的
如业务系统比较规范，变动也极小的情况下，而且etl过程中也不会涉及到多系统之间的标准化过程，则直接使用业务键较好
另外，使用代理键也并不是简单的用序列，代理键的规则选不好的话，ETL的转换量都可能会增多不少
如业务系统比较规范，变动也极小的情况下，而且etl过程中也不会涉及到多系统之间的标准化过程，则直接使用业务键较好
另外，使用代理键也并不是简单的用序列，代理键的规则选不好的话，ETL的转换量都可能会增多不少
