Azure SQL数据仓库代理密钥

因此，Azure SQL数据仓库不支持标识列，因此处理代理键很棘手。。有人有大胆的解决办法吗

---

这是我发现的最好的，而且非常可怕。

这是最好的选择-但是您可以在OVER子句中使用常量值，以避免必须对特定值进行排序，并且不需要使用变量

INSERT INTO testTgtTable (SrgKey, colA, colB)
SELECT
    ROW_NUMBER() OVER(ORDER BY (SELECT 1)) + (SELECT ISNULL(MAX(SrgKey),0) SK FROM dbo.testTgtTable) SK
  , [colA]
  , [colB]
FROM testSrcTable;

---

基于散列的代理键有必要使用Hadoop、NoSQL和其他大数据扩展来取代基于序列的代理键

这里有一些理由可能需要考虑基于序列的基于哈希的代理密钥：

• 在BI生态系统中的不同平台上采用一致的代理密钥生成方法。无论是任何ETL工具（SSIS、DataStage等）、任何NoSQL或MPP数据库或Hadoop实现，都可以在各种环境中独立生成一致的基于哈希的密钥

• 与ETL相比，在ELT实现中，基于哈希逻辑的代理键比基于序列的代理键更有意义。在MPP和BigData解决方案中，“加载数据并进行处理”（ELT）是首选方法。通过用哈希值计算代替查找，简化了数据加载和转换过程。因此，这将从I/O密集型操作（查找）转变为CPU密集型操作（哈希生成）

• 通常，所有数据加载/转换过程都可以完全并行执行，因为可以避免表之间的依赖关系，因为基于哈希的代理键是一致的，并且可以独立生成

• 在实时/近实时数据更新场景中，通常可以通过不需要执行额外的查找（允许跳过暂存区域并直接插入事实表）来动态生成基于哈希的代理键

• 跨开发、UAT和生产环境的一致代理密钥

• 在大多数MPP数据仓库平台上，固定长度散列键上的连接是相当理想的

以下是一些建议：

• 使用自然业务键作为维度表中主键的哈希函数的输入

• 使用组成主键的串联自然业务键作为事实表哈希函数的输入。不要忘记在串联中按特定字符（例如|）分隔业务键，以避免意外冲突

• 使用自然业务键作为哈希函数的输入，以链接到事实表中的维度

---

不过，像往常一样，我要警告你一句！基于散列的代理项键可能会产生冲突，即，给定两个不同的输入值，可能会生成相同的散列值。有关这方面的更多信息，您可以阅读和查看。

有时文件中存在行号，或者可以轻松添加行号。如果存在，则可以利用它来生成代理键值。这是一个多步骤的过程

将数据加载到临时表中

对目标表代理项键执行MAX（）查找以获取当前最大值

CTA或将数据从暂存表插入目标。将max_count常量添加到行数值

代码如下所示：

DECLARE @max_count bigint
SET     @max_count = (SELECT MAX(ID) FROM Fact)

...

CREATE TABLE Input_Load
WITH (DISTRIBUTION = ROUND_ROBIN
     ,CLUSTERED COLUMNSTORE INDEX
     )
AS
SELECT @max_count + RowNumber
,      ...
FROM   dbo.stage_table
;

---

我认为基于业务密钥的散列值的代理密钥不是一个好的解决方案，因为您提出了关于冲突的问题。它违背了代理密钥的目的，即不管BK是什么，都为DW提供唯一的ID。所有“智能”或“智能”密钥的经典问题，或者与使用BK作为PK相关的问题仍然存在。

我们现在在Azure SQL数据仓库中有了标识列功能。

---

标识列功能与CTAS语句不兼容，这大大降低了它作为“解决方案”的可用性。它只适用于在ASDW中表现不佳的插入、更新和删除

，该链接是Azure SQL DW和PDW的既定模式。你会习惯的：）哦，ADW现在支持身份激动人心：）