設計大型實體的最佳實踐

設計一個大型實體（如包含超過100個屬性的Employee表）的最佳做法是什麼？設計大型實體的最佳實踐

我是否應該將它們作爲一個包含100列的單獨表格，或者我應該將它們拆分爲1..1關係，然後在我的代碼中組合Employee對象？

有沒有意見？每種方法的優缺點？

來源

2012-10-15 Pluc

有很多事情是可以進入這樣的一個決定。首先要問的是，是否真的有100個與每個員工有關的個人屬性？* –

這實際上取決於您將使用什麼信息，您將更新信息的頻率，您將如何消耗信息等。如果你正在做一些數據倉庫，那麼在表中有100列的數據是完全正確的。不過，更傳統的交易系統可能會給這種方法帶來問題。 – SchmitzIT

@AdamRobinson是的，真的有100個左右的屬性。這個表格將包含員工姓名，社交號碼，薪水和保險信息的所有內容。每個員工都有這些信息，或者在一段時間後會有這些信息。 – Pluc

這裏的答案不在Employees表中，而在於更廣泛的數據庫設計。如果所有的屬性肯定是1-1，那麼我肯定會有一個實體。 SQL Server在進行物理設計時可以使用優化，如用於具有多個NULL值的列的SPARSE列。

我假設您目前正在經歷規範化和實體關係圖的過程。如果你是，那麼我會建議看一下SuperType/SubType的方法，通常僱員通常是一個很好的候選人。

在這種方法中（例如），您可能會有一個「聯繫人」表，其中包含名字，姓氏，電話號碼等。然後這些表將鏈接到您的Employees表，您的Customers表，您的Vendors表等等。然後，您的員工表將包含員工特有的屬性，例如員工編號，開始日期等。

這有幾個好處。

首先，如果員工也是客戶，例如，那麼您減少了數據冗餘。
您可能會獲得更好的壓縮比。這是因爲當您的列數較少時，頁面上會存儲更多的行，這意味着名稱「Smith」將更頻繁地出現在同一頁面上。
從主數據的角度來看，如果引入了電子郵件列的數據類型的公司標準，則可以在一個地方而不是三個地方對其進行更改。（請原諒這個稍微做作的例子，但希望它能說明這一點）。
由於超級表和子表都有較少的列，所以每個都可以更快地隔離讀取。如果在相同的查詢中加入並放置在單獨的光盤上，則可以並行讀取2個表。

來源

2012-10-15 14:47:46

我認爲這種方法（不知道它被稱爲超類型/子類型），但我不確定的好處是什麼。聯繫人實體只能在單個員工實例中使用。我永遠不會使用聯繫人表的ID來保留對員工聯繫人姓名的引用，因爲我會感興趣的信息會更多（例如，想知道員工薪水以計算價值的成本系統他投入的時間）。這感覺就像一個無用的曲子，我看不出優點。 – Pluc

@Pluc：超級/子類型關係的點與OO設計中的繼承（或LSP）的概念非常相似;也就是說，在皮特的例子中，每一個「員工」都是「聯繫人」，但是可能還有其他的「聯繫人」記錄不是*員工。通過允許將常用屬性存儲在一個表中，然後創建存儲特定於其他類型的信息的簡單相關表，這非常有用。替代方案要麼是在所有表格中複製這些屬性，要麼使用一個有大量空值的巨大表格。 –

（續）如果你沒有這種關係，那麼這種方法不適合你的問題。 –

試試看Star-Schema和Snowflake-Schema。這些是設計數據倉庫模式時使用的術語，其優點和缺點可能與您在此面臨的問題非常相似。

http://en.wikipedia.org/wiki/Star_schema

http://en.wikipedia.org/wiki/Snowflake_schema

http://www.diffen.com/difference/Snowflake_Schema_vs_Star_Schema

來源

2012-10-15 14:58:57 SchmitzIT

設計大型實體的最佳實踐

回答

相關問題