SQL Server中的Data Vault 2.0

Question

在data vault 2.0中，对业务键进行哈希处理，并将此哈希值作为表的主键。 此外，链接表使用哈希主键创建关系。

我的问题是哈希基本上是随机的，查询优化不能应用任何好的估计，因为统计 - 当然 - 不能用于随机分布式数据。

因此查询优化器使用他想要经常排序的奇怪平面（因为它认为只有4行要排序）。既然我肯定不是第一个在sql server中处理数据保险库的人，那么这个怎么可以修复？。

当查询优化器使用索引查找或连接运算符时，它完全错过了行估计，因此选择了荒谬的计划。

我必须使用连接提示和查询提示（例如（FORCE ORDER））对它们进行操作，以便从中获取任何内容。

这是什么常见方法？

Answer 1

我坚信你的结论是，哈希将使所有具有结构/顺序的数据完全随机，这将使任何形式的有用数据库统计都不可能。

我实际上自己做了一些关于 SQL服务器的实验，并得到了与你一样的结论，得到了解释计划的支持

这就是为什么我坚信你/我们应该考虑使用连接的商家密钥作为哈希的主键 INSTEAD 。< / p>

为散列提供的参数属于以下范围：

1. 加入Char（32）（MD5哈希的字符串）与加入变量字符字段相比，更高效
2. 在写入数据时，哈希减少MPP群集中的热点

但是我还没有看到论证1的证据：正如你提到的那样，你在加入时会失去任何有用的统计数据！此外：我知道很多自然商业密钥实际上 SMALLER 超过32个字符......几天前我实际上有asked a question与此主题相关...

然后参数2：在大多数 MPP NoSQL数据库（键值，文档，列族）中，建议实际上是使用好的 NATURAL < / strong>（连接）键作为分片键，而不是哈希。示例：请参阅this advise了解Cassandra。

这就是我不同意与Data Vault 2 Hashing理论的原因：我还没有看到任何证明支持这个...这是为什么我在10月份提出了一个新的Ensemble modeling approach @ DMZone柏林。

Answer 2

就我个人而言，我不会对BK进行散列，但如果它是复合键，则会包含HUB中的所有字段。为什么LINK表会使用哈希值，它应该使用HUB_ID，我总是将其设置为递增值

然而，我会在SAT表中创建并存储HASH，因为这是检查ETL过程中更改的最快方法：散列进入的值并与当前SAT记录中的散列进行比较 - 重新计算中没有任何意义现有记录的哈希值。