大型項目的兩表數據庫設計

Question

我正在開始一個相當復雜的項目，該項目最終將用於運行多個部門（人力資源，財務等）以及保存客戶數據等。我已經獲得了數據庫設計文檔，該文檔解釋了以前的版本個人（不再在身邊）想設計數據庫。 這是我從未見過的設計。 簡化的想法是在表上保存實際數據，在第二張表上將數據組合成邏輯單元。

例如，這將是第一個包含數據的表：

KEY, DATA
0,   Name
1,   First Name
2,   Last Name
3,   Position
4,   Title
5,   Reports To
6,   John
7,   Smith
8,   Developer
9,   CTO

這是結合數據的第二張表：

KEY, GROUP_KEY, DATA_KEY, CHILD_KEY
0,   NULL,      0,        NULL
1,   0,         1,        2
2,   0,         2,        NULL
3,   NULL       3,        NULL
4,   3,         4,        5
5,   3,         5,        NULL
6,   0,         6,        7
7,   0,         7,        NULL
8,   3,         8,        9
9,   3,         9,        NULL

基本上，第二個表中的第一行（鍵0）定義了一個名為Name的新分組。 接下來的兩行定義了屬於該組的“列”。 第四行（鍵3）定義了另一個稱為位置的分組，下面的兩行再次定義了屬於該組的“列”。 最后四行將值John和Smith分配給組Name，將值Developer和CTO分配給Position。

這被大大簡化了，但是我希望它給出了所建議的數據庫結構的基本思想。 一個表用於保存數據庫中可能存在的所有可能值，第二個表將這些值組合為任何可能的組合。

我的新經理不太喜歡這種設計，就我個人而言，我從來沒有遇到過這種設計。 由於這將是一個使用Entity框架或NHibernate與數據庫進行交互的C＃項目，因此這種數據庫設計似乎對於在這兩個框架中的任何一個實施都將是一個挑戰。 這種設計是否有名稱，以便我進一步研究？ 此設計有哪些主要利弊？ 該文檔提到這樣做是為了獲得更好的性能和“超”標准化。

Answer 1

這看起來像“ 內部平台”反模式 。 您已經有了RDBMS，而不是像將其標准化為關系文件一樣，而是決定像平面文件一樣使用它並將每個數據轉儲到單獨的行中，期望通過在運行時通過連接魔術鍵列將這些行組合為關系。

我從來沒有見過這項工作很好； 性能糟糕透頂，沒有約束，因此數據到處都是丟失或重復，沒有鍵關系，因此沒有辦法強制執行有效性，常規的數據庫操作（如聚合和分組）必須使用過程邏輯手動完成。 您基本上是在使用數據庫來實現數據庫。

您的建築師可能認為他們提供了“可擴展性”。 看！ 您可以將任何類型的任何數據添加到數據庫的末尾！ 這很少有用。 這使得查找數據和執行有效性幾乎變得不可能。 如果確實需要在運行時添加任何數據類型，則自1970年代以來的每個SQL數據庫都允許動態SQL和在運行時更改架構。

-1。 不會再次購買。