Datavault：如何获取外键关系的哈希值（填充 link 表）
Datavault: How to get hashes for foreign key relationships (populating link tables)
我已经从头到尾阅读了数据保险库一书，但我仍在尝试解决与如何填充 link table 相关的具体问题（如何获取所有哈希）。来自 scalefree 的博客：massively parallel processing，它演示了卫星和集线器可以以完全并行的方式加载，但它没有涉及与 link table 相关的很多细节s.
链接需要散列键，因此以某种方式 'business keys' 从多个 table 建立关系，这就是他们所做的，他们记录中心之间的关系。在填充这些 link table 时，没有很好的解释或深入的解释如何检索相关实体的业务密钥。
对于像 'customer' 这样的特定 table，集线器和卫星很容易：只需将业务密钥转换为散列并并行加载它们。
但是来自 OLTP 的客户详细信息 table 或交易 table 需要某种连接才能恰好查找客户的业务键或查找中的所有相关实体交易（产品、客户、商店等），因为那些 table 通常不会将（所有）业务密钥存储为 table.
中的属性
如果我假设暂存是增量加载和截断的，那么暂存不一定加载所有实体才能在那里执行连接。如何解决这个难题并创建有效的设计？
- 加入源 OLTP 系统中的 tables 以从那里生成业务密钥并将它们作为散列从那里传播？ （如果业务密钥选择不正确，这最终会出错）
- 使用持久暂存区，所以永远不会截断？ （然后总是可以加入其中的任何 table 来解决）
- 对代理键使用某种索引 -> 业务键并从那里执行查找？ （进一步最小化 I/O 并且是增量暂存和持久暂存之间的混合）。
- 其他方法...?
基本上，为您的 OLTP 系统的所有外键关系生成哈希值的最佳做法是什么？
我和一位专家谈过这个问题，这是我从他那里得到的答案：
为 table 生成散列的唯一明智的两种方法是：table 没有为 table 生成业务密钥所需的所有列：
- 如果您拥有所有具有业务密钥的 table 的完整负载（但对于 link table 可能是增量的），加入相关的source tables 在暂存中具有业务密钥。这没关系，因为您可以保证那一刻您拥有所有数据。
- 如果您有 table 具有业务密钥的增量负载，则必须使用持久暂存区 (PSA) 来为您执行此操作。
在源系统查询中加入 tables 以生成业务密钥被认为是不好的做法。原因是数据仓库应该对操作的影响尽可能小。
我已经从头到尾阅读了数据保险库一书，但我仍在尝试解决与如何填充 link table 相关的具体问题（如何获取所有哈希）。来自 scalefree 的博客：massively parallel processing，它演示了卫星和集线器可以以完全并行的方式加载，但它没有涉及与 link table 相关的很多细节s.
链接需要散列键，因此以某种方式 'business keys' 从多个 table 建立关系，这就是他们所做的，他们记录中心之间的关系。在填充这些 link table 时，没有很好的解释或深入的解释如何检索相关实体的业务密钥。
对于像 'customer' 这样的特定 table，集线器和卫星很容易：只需将业务密钥转换为散列并并行加载它们。
但是来自 OLTP 的客户详细信息 table 或交易 table 需要某种连接才能恰好查找客户的业务键或查找中的所有相关实体交易（产品、客户、商店等），因为那些 table 通常不会将（所有）业务密钥存储为 table.
中的属性如果我假设暂存是增量加载和截断的，那么暂存不一定加载所有实体才能在那里执行连接。如何解决这个难题并创建有效的设计？
- 加入源 OLTP 系统中的 tables 以从那里生成业务密钥并将它们作为散列从那里传播？ （如果业务密钥选择不正确，这最终会出错）
- 使用持久暂存区，所以永远不会截断？ （然后总是可以加入其中的任何 table 来解决）
- 对代理键使用某种索引 -> 业务键并从那里执行查找？ （进一步最小化 I/O 并且是增量暂存和持久暂存之间的混合）。
- 其他方法...?
基本上，为您的 OLTP 系统的所有外键关系生成哈希值的最佳做法是什么？
我和一位专家谈过这个问题，这是我从他那里得到的答案：
为 table 生成散列的唯一明智的两种方法是：table 没有为 table 生成业务密钥所需的所有列：
- 如果您拥有所有具有业务密钥的 table 的完整负载（但对于 link table 可能是增量的），加入相关的source tables 在暂存中具有业务密钥。这没关系，因为您可以保证那一刻您拥有所有数据。
- 如果您有 table 具有业务密钥的增量负载，则必须使用持久暂存区 (PSA) 来为您执行此操作。
在源系统查询中加入 tables 以生成业务密钥被认为是不好的做法。原因是数据仓库应该对操作的影响尽可能小。