如何在插入數據庫等“數據倉庫”之前“規範化”外部數據？
我想成為數據庫不可知論者，但假設我們將數據插入到用作數據倉庫的 SQL Server 中。
電子郵件平台有數百萬條電子郵件記錄，雖然技術上不太好。它的數據沒有標準化。
因此，例如，一個導入可能是 700 萬條記錄，其中一個重要欄位是一個主題行（用於測試目的），並且該主題行是“Happy Mother’s Day One and All, we love Long Texts！” 所有 700 萬條記錄。
現在將“700 萬個完全相同的長文本”添加到大約 50 個不同的主題行中。在這個例子中，標準化的好處再清楚不過了。將高度冗餘的長文本轉換為整數，然後儲存一個小維表，將它們轉換回文本。對？
我只是想知道這個的確切實現。
我將使用 ETL 工具（一個或另一個），但我想有多種方法可以做到這一點。我想我會嘗試將“主題”轉換為基於小維度表的 int，如果找不到匹配項，我會採用不同的新記錄並將它們附加到一個自動遞增的表中？只是想知道這是否是一項常見任務。
在插入數據倉庫之前對有氣味的數據進行規範化。我不是指清理、審計、分析 — 我指的是字面數據庫規範化以縮小數據量。
您描述的整個過程是在數據庫引擎本身中實現的，用於列儲存壓縮。
數據庫引擎將掃描數據以查找重複文本、查找重複項並創建字典表。在行數據中，它將只保留對字典的最少引用。
確保在插入期間保持足夠大的數據批次以觸發此壓縮過程 - 請遵循以下指南：列儲存索引 - 數據載入指南
查找傳入的字元串是否已經存在於維度表中會很慢。您要做的是將任意長的字元串映射到整數代理鍵。這對我來說聽起來像是一個雜湊。
當值被寫入暫存表時，計算字元串的雜湊值並將其儲存。此雜湊將用作維度中的代理鍵。將散列值和其他值複製到事實表。將雜湊和長字元串合併到維度表中。
這裡有幾個可能的問題。一是雜湊將隨機分佈在可能的範圍內。會有差距，負數，並且沒有感覺在更大的數字之前存在更小的數字。由於這是一個內部代理，它真的沒關係。但對人類來說，它經常發生。
第二個問題是可能存在雜湊衝突，其中兩個不同的字元串產生相同的雜湊值。使用幼稚的實現，這將導致數據損壞 - 讀取的值與寫入的值不匹配。根據散列的計算方式，衝突的機率可能非常小。如果後果很小，您可能可以忍受。如果專業，您可能需要編寫額外的程式碼來解決該問題。