Question

所以Azure SQL数据仓库不支持标识列，因此处理代理键很棘手..任何人都有这个大胆的解决方案吗？

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

Answer 1

这是最好的选择 - 但您可以在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;

Answer 2

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

将数据加载到临时表
对目标表Surrogate键执行MAX（）查找以获取当前最大值
CTAS或将登台表中的数据插入目标。将max_count常量添加到row_number值

代码看起来像这样：

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
;

Answer 3

标识列功能与CTAS语句不兼容，这大大降低了它作为“解决方案”。它仅适用于在ASDW中表现不佳的INSERTS，UPDATES，DELETES

Answer 4

基于哈希的代理键有意义用the moving from SMP to MPP Data Warehouses替换基于序列的代理键，并引入Hadoop，NoSQL和其他大数据BI生态系统的扩展。

为什么可能想要考虑基于排序的代理键而不是基于序列的代码键，这有几个原因：

在BI生态系统中的各种平台上生成一致的代理键生成方法。无论是任何ETL工具（SSIS，DataStage等），任何NoSQL或MPP数据库或Hadoop实现，都可以在各种环境中独立生成一致的基于散列的密钥。
与ETL相比，基于哈希逻辑的代理键对ELT实现中基于序列的代理键更有意义。＆＃34;将数据加载到然后处理它＃34; （ELT）是MPP和BigData解决方案的首选方式。通过使用哈希值计算替换查找来简化数据加载和转换过程。因此，这从I / O密集型操作（查找）转移到CPU密集型操作（哈希生成）。
通常所有数据加载/转换过程都可以完全并行执行，因为可以避免表之间的依赖关系，因为基于散列的代理键是一致的，可以独立生成。
通常在实时/接近实时的数据更新方案中，可以通过消除执行额外查找的需要即时生成基于散列的代理键，这些查找允许跳过暂存区域并执行插入操作直接进入事实表。
开发，UAT和生产环境中的一致代理键。
在大多数MPP数据仓库平台上加入固定长度哈希键是相当理想的。

以下是一些建议：

使用自然业务键作为维度表中主键的哈希函数的输入。
使用连接的自然业务键组成主键作为事实表的哈希函数的输入。不要忘记按特定字符分隔串联的业务键，例如|，以避免意外碰撞。
使用自然业务键作为哈希函数的输入，用于链接到事实表中的维度。

然而，像往常一样，一句警告！基于散列的代理键可能会产生冲突，即，在给定两个不同的输入值的情况下可以生成相同的散列值。有关详细信息，请参阅here和here。

Answer 5

我不认为基于业务密钥的哈希值的代理键是一个很好的解决方案，因为您在冲突方面存在问题。它违背了代理键的目的，即为DW提供唯一的ID，而不管BK如何。所有关于＆＃34; Intelligent＆＃34;的经典问题或者＆＃34; Smart＆＃34;密钥或与将BK用作PK相关的问题仍然存在。

Answer 6

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

Azure SQL数据仓库代理键

6 个答案: