表設計 - 寬表與列作爲屬性

Question

我是使用SQL Server 2012構建操作數據存儲（ODS）數據庫的團隊成員之一，該數據庫將由我們的一些分析師用於執行預測性建模。 ODS將包含我們生產的單一產品的製造生產數據。

我們將在ODS中有數百個表格。但是，我們將有一個核心表，其中將包含有關每個製造項目（每年數千萬）的關鍵信息（生命週期信息）。我們的產品在製造工廠製造，並沿生產線的各個流程移動大約2.5小時。我們希望將各種各樣的製造和後期製造信息存儲在此核心表格中。一個示例數據可能是產品進入特定烤箱的時間。

我們決定如何構建此表。我們可以創建一個寬表（多列）或一個窄表，其中大多數列是行（作爲屬性值）。我從來沒有設計和使用非常狹窄的表格結構，並將列視爲表中的行。

我想就寬桌與窄桌的優缺點進行一些反饋。

產品數量每年生產：下面可能會在本次討論幫助是有用的數百萬個（每個產品實例的將是核心表中的行）

請問這個表中經常查詢：是的，很多時候。它將成爲許多子表的父項。

列（或行性）的潛在數量：75到150+

如果有更多的信息是有用的，我很樂意提供。

Answer 1

寬的表，靜態屬性

您正在跟蹤的單品通過良好定義的製造工藝。這個數據模型聽起來非常靜態，並且適用於一個寬表，其中包含許多一致填充數據的列。

窄表，動態性能

如果你有很多很多的產品有很多的變化在製造過程中，這將是更適合狹窄的桌子，在那裏你可以很容易地跟蹤添加新特性。

很難查詢一個條案

然而，即使是簡單的窄表可以極其困難的查詢。例如，如果您需要按特定屬性對數據進行排序，那麼該屬性在100多個其他屬性行中進行混洗時會發生什麼情況？你如何將所有的行組合起來形成一個單獨的「記錄」，然後對結果集中的記錄組進行排序？

平桌簡單的查詢

取決於你需要如何查看和分析數據，你可以不斷利用樞軸或交叉表查詢發現自己。如果是這樣的話，那麼爲什麼不把平坦的表格放在首位呢？

或者兩者都做

另一種選擇是做兩件事：狹義儲存數據，並使用一個轉化過程，以壓平，便於報告。通過這種方式，您可以快速開始跟蹤新屬性（只需添加行），然後就可以更新報告表和轉換過程以利用新數據。

Answer 2

寬度太寬？那麼寬桌子可能會有幾個問題。

一個問題是寬表往往偏離了規範化數據規則。這反過來可能會導致棘手的更新問題，您必須小心防止數據庫進入自相矛盾的狀態。這裏沒有特別的答案，它有多寬。只需應用規範化規則，就可以分解表格了。

但是，有些數據庫不是以規範化作爲指導原則。特別是，考慮星形模式中的事實表。有些時候，某些coulmns是由FK的某些子集確定的，這可能違反3NF甚至2NF。保持事實數據表在骨子模式中仍然很重要，但它的原因是不同的，即速度。有時，通過將數據推送到其中一個維度表，可以使事實表變得更瘦。有時，你可以將一顆恆星分解成兩顆或更多相關的恆星。

您的情況聽起來像上面給出的第二個原因，即使您的設計可能不是星型模式。儘管如此，星型模式設計原則可能會幫助您改進設計。