为什么通过数据仓库建模在维度 table 中使用序列号和版本号
why using sequence number against version number in dimension table by datawarehouse modeling
在维度建模的上下文中，作为典型案例，在维度 table 中使用代理键来跟踪行的变化（http://www.kimballgroup.com/2006/07/design-tip-81-fact-table-surrogate-key/）是很好的。
surrogate key的常见实现方式有3种 1) 序列号 2) 版本号 3) hash key (data vault使用)
我的问题是：为什么在我看到的大多数维度建模中都首选序列号。
非常感谢
我认为通常使用序列号有几个原因，但我认为这并不是在所有情况下都明显优越的做事方式。
序号
优点
- 序号很简单。它们是如此简单得离谱，以至于对于大多数目的来说，考虑其他任何事情都是浪费时间。不要让任何人告诉你这不是我们使用它的原因。
- 序列号保证唯一。
- 序列号尽可能小（窄）。
- 序列号不编码任何信息，因此更改内容甚至维度粒度都没有关系，只要事实知道即可。这很重要，因为维度的粒度很容易改变，因此你 不应该使用具有有意义数据的代理键 （这有点像代理键的要点，至少在 Kimball- ian DWs)
缺点
- 序列号本质上是对 space 的浪费——如果你能在其中编码信息，即使将它变成一个更大的列，你也可以节省 space。不过请参阅上面的优点...
- 我记得看到一些关于序列号的帖子有时会因为页面锁定而导致写入性能不佳，但我现在找不到了。这可能会导致加载缓慢。
版本号
我以前没见过这方面的例子，谷歌搜索似乎出现了这个问题和一些将其附加到现有字段的参考，所以我假设你是在谈论附加序列或散列或其他标识符的版本。
优点
- 您可以访问数据的版本号
- 这可能是一种唯一化自然键的方法，以便您可以将其用作 DW 维度键
缺点
- 最大的缺点是如果不从密钥中删除数据就无法访问这些数据。为什么不把它作为一个单独的列？
- 自然键在 DW 中通常是不好的做法，因此如果这是您的动机，您可能需要重新考虑您的方法。
哈希
如果您不打算使用序列号，这可能是我的首选。虽然我认为需要一些非常具体的情况
优点
- 非常适合类型 2 缓慢变化的维度 - 您不必将哈希存储在单独的列中，因此它节省了 space
将信息编码到代理键中的少数情况之一并不意味着为未来的发展捅自己的脚。
缺点
如果您使用的是类型 1 缓慢变化的维度，那么您就是在搬石头砸自己的脚。更新了一个属性？尝试在不删除一半数据库的情况下更新主键，看看你能走多远。
- 它很大。这会使您的事实表变大，并使您的数据库变大。如果您使用的是基于列的压缩，那么具有讽刺意味的是，维度越大（到一定程度...），问题就越大
结论
所以这取决于你的情况，但是序列号很容易实现，而且在几乎所有情况下缺点几乎完全可以忽略不计，以至于它可以作为一个舒适的默认值。因此，选择其他选项通常属于 "you have to explain why you did it" 类别。
在维度建模的上下文中，作为典型案例，在维度 table 中使用代理键来跟踪行的变化（http://www.kimballgroup.com/2006/07/design-tip-81-fact-table-surrogate-key/）是很好的。
surrogate key的常见实现方式有3种 1) 序列号 2) 版本号 3) hash key (data vault使用)
我的问题是：为什么在我看到的大多数维度建模中都首选序列号。
非常感谢
我认为通常使用序列号有几个原因，但我认为这并不是在所有情况下都明显优越的做事方式。
序号
优点
- 序号很简单。它们是如此简单得离谱，以至于对于大多数目的来说，考虑其他任何事情都是浪费时间。不要让任何人告诉你这不是我们使用它的原因。
- 序列号保证唯一。
- 序列号尽可能小（窄）。
- 序列号不编码任何信息，因此更改内容甚至维度粒度都没有关系，只要事实知道即可。这很重要，因为维度的粒度很容易改变，因此你 不应该使用具有有意义数据的代理键 （这有点像代理键的要点，至少在 Kimball- ian DWs)
缺点
- 序列号本质上是对 space 的浪费——如果你能在其中编码信息，即使将它变成一个更大的列，你也可以节省 space。不过请参阅上面的优点...
- 我记得看到一些关于序列号的帖子有时会因为页面锁定而导致写入性能不佳，但我现在找不到了。这可能会导致加载缓慢。
版本号
我以前没见过这方面的例子，谷歌搜索似乎出现了这个问题和一些将其附加到现有字段的参考，所以我假设你是在谈论附加序列或散列或其他标识符的版本。
优点
- 您可以访问数据的版本号
- 这可能是一种唯一化自然键的方法，以便您可以将其用作 DW 维度键
缺点
- 最大的缺点是如果不从密钥中删除数据就无法访问这些数据。为什么不把它作为一个单独的列？
- 自然键在 DW 中通常是不好的做法，因此如果这是您的动机，您可能需要重新考虑您的方法。
哈希
如果您不打算使用序列号，这可能是我的首选。虽然我认为需要一些非常具体的情况
优点
- 非常适合类型 2 缓慢变化的维度 - 您不必将哈希存储在单独的列中，因此它节省了 space
将信息编码到代理键中的少数情况之一并不意味着为未来的发展捅自己的脚。
缺点
如果您使用的是类型 1 缓慢变化的维度，那么您就是在搬石头砸自己的脚。更新了一个属性？尝试在不删除一半数据库的情况下更新主键，看看你能走多远。
- 它很大。这会使您的事实表变大，并使您的数据库变大。如果您使用的是基于列的压缩，那么具有讽刺意味的是，维度越大（到一定程度...），问题就越大
结论
所以这取决于你的情况，但是序列号很容易实现，而且在几乎所有情况下缺点几乎完全可以忽略不计，以至于它可以作为一个舒适的默认值。因此，选择其他选项通常属于 "you have to explain why you did it" 类别。