沒有域值的表規範化

我們的ETL團隊和Data Modeler之間有關於表是否應該規範化的爭論，我希望從網上社區獲得一些觀點。沒有域值的表規範化

目前表設置這樣

 
    MainTable    LookupTable 
    PrimaryKey (PK)   Code (PK) 
    Code (FK)    Name 
    OtherColumns

這兩個表是僅了一個週期性的文件（從第三方）被填充通過ETL作業
- 單記錄在文件中包含兩個表中的所有屬性，對於單個行）
填充這些表的文件是一個增量（只有其中有一些更改的行在文件中）
- 對一個記錄（同樣只有第三方）的一個屬性進行一次更改將導致該數據的所有數據文件
在記錄中的域值的代碼和名稱都 不知道。

問題：LookupTable是否應該非規範化到MainTable中。

ETL團隊：是的。使用此設置，文件中的每一行首先必須檢查第二個表以查看它們的FK是否在其中（如果不是，則插入），然後添加MainTable行。更多的代碼，更糟的表現，並且稍微有更多的空間。但是，無論第三方對LookupTable.Name進行更改，週期性文件都會反映受影響的每一行，而且我們仍然需要解析每行。如果集中到MainTable中，它就是一個簡單的更新或插入。 Data Modeler：這是標準的良好數據庫設計。

有什麼想法？

來源

2013-07-30 user2210179

這些表是OLTP還是DW/BI系統的一部分？尺寸建模與3NF建模不同。 –

這些表格是一組虛擬服務器的備份，可用於虛擬環境。數據的主要來源由Web服務提供。如果/當Web服務出現故障（預期維護或其他原因）時，這些表將提供最後一個已知的數據。他們不會經常受到打擊，但是當他們遭受打擊時，他們將受到重創。 – user2210179

第三方的webservice是維護人員。我們的呼叫將被映射到這個數據庫，而不是從他們那裏得到響應。 – user2210179

構建原型。進行測量。

您從此開始，您的數據建模師說這是一個標準的良好數據庫設計。

 
    MainTable    LookupTable 
    PrimaryKey (PK)   Code (PK) 
    Code (FK)    Name 
    OtherColumns

他是對的。但是，這也是一個很好的數據庫設計。

 
    MainTable 
    PrimaryKey (PK) 
    Name 
    OtherColumns

如果這些表的所有更新，從ETL作業來僅，你不需要是非常關心通過外鍵強制執行數據的完整性。 ETL作業無論如何都會將新名稱添加到查找表中，而不管它們的值是什麼。數據完整性主要取決於系統數據是從中提取的。（和ETL作業的質量。）

採用這種設置，從文件的每一行必須首先檢查第二個表，看看他們的FK是在那裏（insert，如果它不是），然後添加MainTable行。

如果他們正在逐行處理，請僱用新的ETL傢伙。認真。

更多代碼，更糟糕的表現，並且稍微有更多空間。

他們需要一個多一點代碼更新兩個表而不是一個。編寫SQL語句需要多長時間？運行它們需要多長時間？（每條路有多長？）

更糟糕的表現？也許。也許不會。如果使用固定寬度的代碼，如整數或char（3），則更新至代碼不會影響行的寬度。由於代碼比名稱短，所以更多的行可能適合頁面。（使用比名稱更長的代碼是沒有意義的。）每頁更多的行通常意味着更少的I/O。

更少的空間，當然。因爲您在「MainTable」的每一行中都存儲了一個短代碼而不是長名稱。

例如，國名的平均長度約爲11.4個字符。如果您使用3個字符的ISO國家/地區代碼，則可以在「MainTable」中每行平均保存8.4個字節。對於1億行，您節省了大約8.4億字節。查找表的大小可以忽略不計，大約6k。

而且你通常不需要連接來獲取全名;國家代碼旨在在不擴展的情況下爲人類可讀的。

來源

2013-07-31 01:40:56

數據intregrity主要用於提醒我們，如果我們的文件可能包含錯誤或丟失的數據。代碼本身並不是人類可讀的， – user2210179

沒有域值的表規範化

回答

相關問題