規範化數據儲存 - 與要使用的前綴混淆
我正在設計一個 Staging+NDS+DDS 數據倉庫系統，其中 ETL 將從中規範化數據
[Staging]並將其載入到[NDS]中，該系統將保存所有歷史記錄。我已經基本完成了 T-SQL 腳本，它將在
[NDS]數據庫中創建表和約束，其中包含主表和事務表，它們將分別以我打算成為星型模式的方式提供[DDS]Dimension和Fact表。我給自己制定了以下規則：
表採購
[DDS]維度前綴為DWD_表採購
[DDS]事實的前綴是DWF_外鍵列以
DWK_代理鍵列的前綴與表的前綴相同。這意味著代理鍵始終是：
DWD_Key對於一張DWD_桌子，或DWF_Key一張DWF_桌子。控制列的前綴與表的前綴相同。例如…
該
DWD_Customers表具有控制列：
DWD_IsLastImageDWD_EffectiveFromDWD_EffectiveToDWD_DateInsertedDWD_DateUpdatedDWD_DateDeleted該
DWF_InvoiceHeaders表具有控制列：
DWF_DateInsertedDWF_DateUpdatedDWF_DateDeleted主鍵（/代理鍵）總是以
PK_表名（包括表前綴）為前綴，例如PK_DWD_Customers和PK_DWF_InvoiceHeaders。我還添加了對自然鍵
unique的約束，並且它們總是以表名（包括表前綴）為前綴，例如and 。NK_``NK_DWD_Customers``NK_DWF_InvoiceHeaders外鍵列總是以
DWK_被引用表的名稱（沒有前綴）和單詞“Key”作為前綴 - 例如DWK_CustomerKey。外鍵約束總是命名為
FK_[ParentTableNameWithPrefix]_[ChildTableNameWithPrefix].當一個表對同一個表有多個 FK 時，FK 列的名稱將附加到約束的名稱，例如
FK_DWD_FiscalCalendar_DWF_OrderDetails_DeliveryDate.所有帶前綴的列都沒有商業意義，永遠不應該出現在視圖中；我發現，這給我留下了一個非常乾淨和一致的設計，並且
create table腳本看起來像這樣：create table DWD_SubCategories ( DWD_Key int not null identity(1,1) ,DWD_DateInserted datetime not null ,DWD_DateUpdated datetime null ,DWK_CategoryKey int not null ,Code nvarchar(5) not null ,Name nvarchar(50) not null ,constraint PK_DWD_SubCategories primary key clustered (DWD_Key asc) ,constraint NK_DWD_SubCategories unique (Code) );所以，我的問題是，在我繼續並實施 ETL 以將數據載入到該數據庫之前，我應該知道（或*忘記）任何事情嗎？*繼承這個數據庫的人會想在未來追捕我並扯掉我的頭嗎？我應該改變什麼來避免這種情況？我詢問前綴的原因是因為我正在使用
DWDandDWF，但這些表在技術上不是“維度”和“事實”表。這很混亂嗎？另外，我不確定自然鍵的概念- 我是否正確假設它應該是源系統可能認為其“關鍵”列的列的唯一組合，我可以在 ETL 過程中使用它來定位，比如說，要更新的具體記錄？
至少還有一些你應該知道的東西，幾乎同樣，總是有**一些你應該有意識地停止的東西。特別是在數據倉庫的背景下，這是一個相對新興的領域，利用了相對較新的技術。
關於我在現實世界中看到的東西，第一次走進一家公司，看到我對你的設計的理解，真的會讓人流淚：喜悅和寬慰的淚水。從一開始，您就可以開始使用經過深思熟慮（精心設計）的 ETL / 數據倉庫系統。與任何軟體產品的實施一樣，您的里程可能會隨著解決方案的增長和業務的消耗而變化，但從根本上說，您處於正確的軌道™（是的，您知道什麼是自然密鑰）。
我發現這些類型的解決方案存在許多挑戰，我將談到這些挑戰以加強您的一些決定，並可能為您提供一些洞察力。
DateInserted首先，由於開發人員（甚至是其他數據庫管理員/數據專業人員）誤解了控制列的上下文（例如，對列執行程序，僅僅一次），我發現自己陷入困境的次數插入郵票，在DateReceived或類似命名的列，旨在將一行與特定的發生日期聯繫起來），雖然我完全同意@Aaron Bertrand 提出的警告，但我覺得您的控制列的前綴實際上可以用作一種標誌來幫助防止他們的濫用。顯而易見的當然應該是顯而易見的，但就像一般編寫程式碼一樣，顯式更可取。也就是說，我幾乎肯定會將這些前綴排除在索引之外（甚至可能是鍵 -PK我認為類型可以而且應該保留，但除非存在真正的威脅DWD_SubCategories並存DWF_SubCategories在於同一架構中，否則它們真的只是絨毛） .DWD我認為對and前綴的關注DWF是有效的，但他們將生活在[NDS]目錄，並將用於表明意圖，從而完全可以以這種方式使用命名法。第二個（也許是最令人氣憤的）挑戰是交叉培訓你的同事。如果你的追求薪水超過卓越的同事參與其中並且做得不夠好（或者公平地說，甚至只是表現不佳），那麼所有的軟體工程、使用標誌和設計實踐規則都是徒勞的日 ）。請記住，大型項目通常有很多手指在鍋中，因此這些手指必須表現良好。
我在這裡要談的最後一件事是始終牢記任何 ETL 系統對企業的實際價值。在 Extract、Transform 和 Load 範例中，第一個和最後一個字母絕對沒有商業價值，因此您將希望盡可能減少 Extract 和 Load 流程的開發和維護——“真正的”工作將在轉換階段完成，因此您將希望盡可能地自動化 E 和 L 步驟，以便您可以專注於通過積極進行轉換來使您的解決方案對業務部門有價值（並保持）。
綜上所述，我只有機會研究少數幾種不同的倉儲解決方案，所以如果我需要糾正，也許一個更有知識的使用者可以介入並從我的嘴裡移開我的腳。正如我一開始所說，這是人們總是可以學習或忘記某些東西的領域之一，我絕對也不例外。
哦，還有一件事（可能是最重要的）——單元測試！一旦您的 E 和 L 按預期工作，並且您有機會通過您的 T 解決方案放置幾個域，請找人審查結果。如果它們很好，請將結果集保存在某個地方，這樣當您進行更改時（毫無疑問，您會這樣做），您可以確保您沒有在其他地方破壞某些東西。再次，盡可能地自動化這個過程（這對業務來說是另一個 0 值過程，直到他們至少沒有它；））。為此，我通常會設置一個單獨的模式或目錄。
希望我說的一些對你有用！
作為更新，@Aaron Bertrand 的模式分離似乎也是避免不必要前綴的好方法，所以一定要考慮這一點（我知道我會哈哈）。