Azure SQL數據倉庫代理鍵

所以Azure SQL數據倉庫不支持標識列，因此處理代理鍵很棘手..任何人都有這個問題的任何大膽的解決方案？Azure SQL數據倉庫代理鍵

This是我發現的最好的，它是非常可怕的。

2016-01-29 m1nkeh

該鏈接是Azure SQL DW和PDW良好建立的模式。你會習慣它:) – GregGalloway

ooo，ADW現在支持身份！ - https://azure.microsoft.com/en-gb/updates/identity-now-supported-in-azure-sql-data-warehouse/ - 令人興奮的:) – m1nkeh

這是最好的選擇 - 但是你可以在你的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;

來源

2016-01-30 03:55:30

基於散列的代理鍵意義與the moving from SMP to MPP Data Warehouses和引進的Hadoop，NoSQL的和其他大數據擴展到您的BI生態系統更換基於序列的代理鍵。

以下是爲什麼可能要在測序基的要考慮基於散列的代理鍵幾方面的原因：跨各種平臺在BI生態系統

一致的代理鍵生成方法。它可以在任何ETL工具（SSIS，DataStage等），任何NoSQL或MPP數據庫或Hadoop實現的各種環境中獨立生成一致的基於散列的密鑰。
與ETL相比，基於哈希邏輯的替代鍵對ELT實現中基於序列的替代鍵更有意義。「將數據加載並加以處理」（ELT）是MPP和BigData解決方案的首選方式。通過用散列值計算替換查找來簡化數據加載和轉換過程。因此，這會從I/O密集型操作（查找）轉移到CPU密集型操作（哈希生成）。
很多時候所有的數據加載/轉換過程都可以完全並行執行，因爲可以避免表之間的依賴關係，因爲基於散列的代理鍵是一致的並且可以獨立生成。
通常在實時/接近實時的數據更新情況下，可以通過消除額外查找的需要即時生成基於散列的代理鍵，從而可以跳過暫存區域並直接插入進入事實表。
橫跨開發，UAT和生產環境的一致的代理鍵。
在大多數MPP數據倉庫平臺上，固定長度哈希鍵的連接是相當優化的。

這裏有幾點建議：

使用自然業務鍵作爲輸入到在維度表的主鍵哈希函數。
使用連接的自然業務鍵組成主鍵作爲事實表的散列函數的輸入。不要忘記通過特定字符來分隔串聯業務密鑰，例如|，以避免意外碰撞。
將自然商業密鑰用作哈希函數的輸入，以便鏈接到實際表中的維。

然而，像往常一樣，一個警告！基於散列的替代鍵可能會產生衝突，即給定兩個不同的輸入值可能會生成相同的散列值。更多關於這個，你可以閱讀here和here。

來源

2016-01-30 10:07:14 drumsta

有時行號存在於文件中或可以很容易地添加。如果它存在，那麼可以利用它來生成代理鍵值。它是一個多步驟的過程

負載數據到一個臨時表
執行對目標表代理鍵一個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 
;

來源

2016-02-10 14:23:58 JRJ

我不認爲基於業務鍵的哈希值代理鍵是因爲一個很好的解決方案非常關心碰撞問題。它違背了代理鍵的目的，即爲DW提供唯一的ID而不管BK。所有與「智能」或「智能」鍵有關的經典問題，或與使用BK作爲PK相關的問題仍然存在。

來源

2017-05-02 15:51:02