为什么使用数据仓库建模在维度表中使用序列号对应的版本号

Question

在维度建模的上下文中，作为典型情况，在维度表中使用代理键来跟踪行的变化（http://www.kimballgroup.com/2006/07/design-tip-81-fact-table-surrogate-key/）是很好的。

实现代理密钥有三种常用方法：1）序列号2）版本号3）散列密钥（由数据库使用）

我的问题是：为什么序列号在我见过的大多数维度建模中都是首选。

非常感谢

Answer 1

我认为通常使用序列号有几个原因，但我不认为这是在所有情况下做事的明显优越方式。

序号

赞成

• 序号很容易。它们非常简单，在大多数情况下，考虑其他任何事情都浪费时间。不要让任何人告诉你这不是我们使用它的原因。
• 序列号保证唯一。
• 序列号尽可能小（窄）。
• 序列号不会对任何信息进行编码，因此只要事实知道，更改维度的内容甚至粒度都无关紧要。这很重要，因为维度的粒度很容易改变，因此你不应该使用具有有意义数据的代理键（这有点代理键，至少在Kimball-ian DWs中）

缺点

• 序列号本质上是浪费空间 - 如果您可以对此进行编码，即使将其设为更大的列，也可以节省空间。见上面的专业人士......
• 我记得有些关于序列号的帖子有时由于页面锁定而导致写入性能不佳，但我现在找不到它。这可能导致加载缓慢。

版本号

我之前没有看过这个例子，谷歌搜索它似乎出现了这个问题和一些引用将它附加到现有字段，所以我将假设你正在谈论将版本附加到序列或散列或其他标识符。

赞成

• 您可以访问数据的版本号
• 这可能是一种独特的方式 - 使用自然键，以便您可以将其用作DW维度键

缺点

• 最大的问题是，如果不将其从密钥中删除，则无法访问此数据。为什么不把它作为一个单独的专栏呢？
• 自然键在DW中通常是不好的做法，所以如果这是你的动机，你可能想重新考虑你的方法。

的哈希

如果你不打算使用序列号，这可能是我的首选。虽然我认为需要一些非常具体的情况

赞成

• 非常适合类型2缓慢变化的维度 - 您不必将哈希存储在单独的列中，因此可节省空间

• 将信息编码到代理键中的次数之一意味着刺伤自己的脚，以便将来发展。

  缺点

• 如果您正在使用类型1缓慢变化的尺寸，那么您只是在脚下刺伤了自己。更新了属性？尝试更新主键而不删除数据库的一半，看看你能得到多少。

• 很大。这会使您的事实表变大，这会使您的数据库变大。如果您正在使用基于列的压缩，这具有讽刺意味的是，维度变得越大（到某一点......）

结论

所以这取决于你的情况，但是序列号很容易实现，并且在几乎所有情况下几乎完全可以忽略不计，直到它作为一个舒适的默认值。因此，选择其他选项通常属于“你必须解释为什么要这样做”的类别。