主數據表設計

我有一個asp.net應用程序，使用大量主數據，如貨幣，國家，城市和許多其他領域特定的主數據。當前數據庫模型對於每種類型的主數據都有一個主表。例如，各個國家/地區都有一個帶有ID和值列的獨立主數據表。對所有其他主數據進行類似。這是管理主數據的正確方法嗎？我願意徹底改變它。我想對此發表意見。還有什麼文章或書籍可以爲我在db建模中的這些場景做好準備嗎？主數據表設計

來源

2012-02-28 Hari Subramaniam

我不知道我明白。你說你有一張像國家，貨幣，城市等的表格，而且它們基本上只是鍵值對，對吧？ – 2012-02-28 15:11:32

@MattGrande。是啊，沒錯。他們大多用來填充前端的下拉列表。 – 2012-02-28 15:13:58

我會說那很好。繼續這樣做！ – 2012-02-28 15:15:03

在關係設計和數據建模中，沒有「主」數據這樣的事情，也沒有「主」表這樣的事情。只有數據和表格。

因此，如果您需要存儲某些有關國家/地區的數據，即使它們只是其名稱，然後創建一個國家/地區表。不過，不要使用身份證號碼。使用ISO country code。這是人類可讀的（大部分），而不需要連接。並確保名稱上有一個唯一的約束，而不僅僅是代碼。如果你可以有兩個國家命名爲「愛爾蘭」，你就犯了一個錯誤。

仔細考慮應該允許誰在該表中插入，更新和刪除行。「每個人」幾乎肯定是錯誤的答案。

當其他表需要存儲現有國家/地區的代碼時，這些表會爲國家/地區表聲明外鍵。

如果你正在談論一個看起來像這樣的「主」表。。。

ID Name 
-- 
1  England 
2  London 
3  Birmingham 
4  Liverpool 
5  British Pound (sterling) 
6  Republic of Ireland 
7  Aughagower 
8  Ballyshannon 
9  Euro

然後，你正在創造更多的問題，有更多的表比你感到舒服。這種反模式的通用名稱是「The One True Lookup Table」。

首先，外鍵在這裏沒用，因爲沒有辦法向用戶展示有效的國家，城市或貨幣可供選擇的列表。如果用戶簡單地從該表中選擇值，英格蘭倫敦的用戶可能會輸入「Eury，Aughagower」。

其次，這是一個事實上不正確的模型。「倫敦」不是指定城市的名稱;儘管如此，「倫敦，英國，英國」，「倫敦，加拿大安大略省」和「倫敦，肯塔基州，美國」都是。如果您的數據庫允許名爲「美國阿拉巴馬州舊金山」的「城市」，那麼您的工作就沒有做好。

第三，該模型不是乾淨可擴展的。貨幣本身比他們的名字有更多有用的屬性。舊英鎊有象徵，英鎊和ISO代碼GBP。我記不起任何在過去30年中使用貨幣名稱而不是其符號或ISO代碼的報告。

最後，正確模擬數據不會「污染」數據庫，也沒有「迷你表」這樣的東西。對數據進行建模可以簡化您的工作，並簡化應用程序代碼。當你建立一個適當的關係模型時，每個表格將存儲一種且僅有的一種事實。如果您遇到問題，您將確切知道在哪裏尋找 - SQL錯誤消息幾乎總是將導致問題的表命名爲名稱。排除國家表格的問題比使用存儲50個或更多不同類型事實的「主」表格更容易。

如果表的數量不堪重負，請考慮將其中的一些放在不同的模式中。隨着您獲得經驗，處理大量名字明確的表將成爲第二性質，並且您將學會忽略與您的即時任務無關的表。

來源

2012-02-28 22:04:00

我看到很多使用Master Data Table（一個存放那些只有「ID」和「Name」屬性的實體的大表）的生產軟件。我發現這個設計很麻煩，但是另一個選項用幾個迷你表來監控數據庫方案。那麼...... Master Data是一個糟糕的設計實踐？ – 2012-02-28 22:09:48

@CarlosGavidia：是的，「主」表是一個糟糕的設計實踐。看到我更新的答案。 – 2012-02-29 12:36:25

爲查找數據的每個種類提供單獨的表格是合理的。這允許正確執行參照完整性。

E.g. COUNTRY_ID字段（在某些「非查找」表中）有一個FOREIGN KEY引用COUNTRY表，CURRENCY_ID引用CURRENCY表等......每個字段引用適合該特定字段的表。

來源

2012-02-29 00:50:14

主數據表設計

回答

相關問題