在 Data Vault 2.0 中，对业务键进行散列处理并将该散列作为表的主键。链接表也使用散列主键来创建关系。
我的问题是散列基本上是随机的，查询优化器无法应用任何好的估计，因为统计信息 - 当然 - 不适用于随机分布的数据。
所以查询优化器使用奇怪的计划来经常排序（因为它认为只有 4 行要排序）。既然我肯定不是第一个在 sql server 中处理数据保险库的人，那么如何解决这个问题？
当查询优化器使用索引查找或连接运算符时，它完全错过了行估计，因此选择了荒谬的计划。
我必须用连接提示和查询提示（例如（FORCE ORDER））来拉皮条，以从中得到任何东西。
常见的方法是什么？
我完全同意您的结论，即散列会使所有具有结构/顺序的数据完全随机，这将使任何形式的有用数据库统计信息成为不可能。
实际上，我自己在SQL Server上进行了一些实验，并得到了与您相同的结论，并得到了解释计划的支持
这就是为什么我坚信您/我们应该考虑使用连接的业务密钥作为主键而不是散列它。
为散列提供的参数在以下领域：
但是我还没有看到论点 1 的证据：正如您所提到的，您在加入时会丢失任何有用的统计数据！此外：我知道的很多自然业务密钥实际上都比32 个字符小得多......我实际上几天前问过一个与这个主题相关的问题......
然后到论点 2：在大多数MPP NoSQL 数据库（键值、文档、列族）中，建议实际上是使用一个好的NATURAL（连接）键作为分片键，而不是哈希。示例：请参阅有关 Cassandra 的此建议。
这就是我不同意Data Vault 2 散列理论的原因：我没有看到任何支持这一点的证据……这也是我在 10 月在柏林 DMZone提出新的集成建模方法的原因之一。
就我个人而言，我不会散列 BK，但如果它是复合键，我会包含 HUB 中的所有字段。为什么 LINK 表会使用哈希值，它应该使用 HUB_ID，我总是将其设置为递增值
但是，我会在 SAT 表中创建并存储一个 HASH，因为这是检查 ETL 过程中变化的最快方法：对传入的值进行哈希处理并与当前 SAT 记录上的哈希值进行比较——重新计算哈希值没有意义现有的记录。