所以 Azure SQL 数据仓库不支持标识列，因此处理代理键很棘手。有人对此有任何大胆的解决方案吗？
This 是我找到的最好的，而且非常可怕。
【问题讨论】：
标签： azure data-warehouse azure-sqldw parallel-data-warehouse
这是最好的选择 - 但您可以在 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;
【讨论】：
有时文件中存在行号或可以轻松添加。如果存在，则可以利用它来生成代理键值。这是一个多步骤的过程
代码如下所示：
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
;
【讨论】：
我不认为基于业务密钥哈希值的代理密钥是一个好的解决方案，因为您提出的有关冲突的问题。它违背了代理键的目的，即为 DW 提供唯一 ID，而不管 BK 是什么。 “智能”或“智能”键的所有经典问题，或与将 BK 用作 PK 相关的问题仍然存在。
【讨论】：
我们现在在 Azure SQL 数据仓库中具有标识列功能。 Link
【讨论】：
Identity 列功能与 CTAS 语句不兼容，大大降低了它作为“解决方案”的作用。它仅适用于在 ASDW 中表现不佳的 INSERTS、UPDATES、DELETES
【讨论】：
基于哈希的代理键可以用the moving from SMP to MPP Data Warehouses 替换基于序列的代理键，并引入 Hadoop、NoSQL 和其他大数据扩展您的 BI 生态系统。
以下是为什么要考虑基于散列的代理键而不是基于序列的代理键的几个原因：
跨您的 BI 生态系统中的各种平台的一致代理密钥生成方法。可以在各种环境中独立生成一致的基于哈希的密钥，可以是任何 ETL 工具（SSIS、DataStage 等）、任何 NoSQL 或 MPP 数据库或 Hadoop 实现。
与 ETL 相比，在 ELT 实现中，基于哈希逻辑的代理键比基于序列的代理键更有意义。 “将数据加载到然后处理它”（ELT）是 MPP 和大数据解决方案中的首选方式。通过用哈希值计算替换查找来简化数据加载和转换过程。因此，这会从 I/O 密集型操作（查找）转变为 CPU 密集型操作（哈希生成）。
通常所有数据加载/转换过程都可以完全并行执行，因为可以避免表之间的依赖关系，因为基于哈希的代理键是一致的并且可以独立生成。
通常在实时/近实时数据更新场景中，可以通过消除允许跳过暂存区域和执行插入的额外查找的需要即时生成基于散列的代理键直接进入事实表。
跨开发、UAT 和生产环境的一致代理键。
在大多数 MPP 数据仓库平台上，固定长度哈希键上的连接是相当理想的。
以下是一些建议：
使用自然业务键作为维度表中主键的哈希函数的输入。
使用构成主键的串联自然业务键作为事实表哈希函数的输入。不要忘记按特定字符将业务键串联起来，例如|，避免意外碰撞。
使用自然业务键作为哈希函数的输入，以链接到事实表中的维度。
但是，像往常一样，警告一句！基于散列的代理键可能会产生冲突，即给定两个不同的输入值可以生成相同的散列值。更多相关信息，您可以阅读here 和here。
【讨论】：