84669 人學習
152542 人學習
20005 人學習
5487 人學習
7821 人學習
359900 人學習
3350 人學習
180660 人學習
48569 人學習
18603 人學習
40936 人學習
1549 人學習
1183 人學習
32909 人學習
我在表格設計方面沒有太多經驗。我的目標是建立一個或多個滿足以下要求的產品表：
支援多種產品（電視、手機、PC...）。每種產品都有不同的參數集，例如：
手機將有顏色、尺寸、重量、作業系統...
PC 將擁有 CPU、HDD、RAM...
參數集必須是動態的。您可以新增或編輯您喜歡的任何參數。
如果沒有針對每種產品的單獨表格，如何滿足這些要求？
@StoneHeart
我會一直使用 EAV 和 MVC 來到這裡。
@比爾·卡文
您在這裡提到的所有這些事情：
在我看來，根本不屬於資料庫，因為沒有任何資料庫能夠像應用程式的程式語言那樣在適當的層級上處理這些互動和需求。
在我看來，以這種方式使用資料庫就像用石頭錘釘子一樣。您可以用石頭來完成此操作，但您不應該使用更精確且專門為此類活動設計的錘子嗎？
可以透過對部分資料進行少量查詢並使用應用程式將其處理為表格佈局來解決此問題。即使您有 600GB 的產品數據，如果您需要此表中每一行的數據，也可以批量處理它。
進一步如果您想提高查詢的效能，您可以選擇某些操作，例如報告或全域文字搜尋並為其準備索引表，該索引表將儲存所需的資料並定期重新生成，假設每30 分鐘重新生成一次。
您甚至不需要擔心額外資料儲存的成本，因為它每天都變得越來越便宜。
如果您仍然關心應用程式執行的操作的效能，您始終可以使用 Erlang、C 、Go 語言來預處理數據，然後在主應用程式中進一步處理最佳化後的資料。 p>
您至少有以下五個選項來對您所描述的類型層次結構進行建模：
單表繼承：一個表格適用於所有產品類型，有足夠的欄位儲存所有類型的所有屬性。這意味著很多列，其中大多數在任何給定行上都是 NULL。
類別表繼承：一張產品表，儲存所有產品共有的屬性類型。然後每種產品類型一個表，儲存特定於該產品類型的屬性。
具體表繼承：沒有通用產品屬性的表。相反，每種產品類型一張表，儲存常見產品屬性和產品特定屬性。
序列化 LOB：一個產品表，儲存所有產品類型通用的屬性。一個額外的欄位以 XML、YAML、JSON 或某種其他格式儲存半結構化資料的 BLOB。此 BLOB 可讓您儲存特定於每種產品類型的屬性。您可以使用奇特的設計模式來描述這一點，例如 Facade 和 Memento。但無論如何，您都無法在 SQL 中輕鬆查詢大量屬性；您必須將整個 blob 提取回應用程式並在那裡進行排序。
Entity-Attribute-Value：一張產品表，以及一張將屬性旋轉到行而不是列的表。就關係範式而言，EAV 並不是一個有效的設計，但仍然有很多人使用它。這就是另一個答案提到的「屬性模式」。請參閱 StackOverflow 上使用 eav 標記 的其他問題，以了解一些陷阱。
我在簡報可擴展資料建模中寫了更多相關內容。
關於 EAV 的其他想法：雖然很多人似乎喜歡 EAV，但我不喜歡。這似乎是最靈活的解決方案，因此也是最好的解決方案。但是，請記住這句格言 TANSTAAFL。以下是 EAV 的一些缺點：
NOT NULL
JOIN
EAV 的靈活性程度需要您在其他方面做出犧牲，這可能會使您的程式碼比以更傳統的方式解決原始問題更複雜（或更糟）。
並且在大多數情況下，沒有必要具有這種程度的靈活性。在OP關於產品類型的問題中，為每個產品類型建立一個用於產品特定屬性的表格要簡單得多，因此至少對於相同產品類型的條目強制執行一些一致的結構。
只有當必須允許每一行可能有一組不同的屬性時，我才會使用 EAV。當您的產品類型有限時，EAV 就顯得有些過分了。類別表繼承將是我的第一選擇。
2019 年更新：我越多看到人們使用 JSON 作為「許多自訂屬性」問題的解決方案，我就越不喜歡該解決方案。即使使用特殊的 JSON 函數，它也会使查询变得过于复杂> 來支援他們。與儲存在普通的行和列中相比，儲存 JSON 文件需要更多的儲存空間。
基本上，這些解決方案在關聯式資料庫中都不是簡單或有效的。擁有「可變屬性」的整個想法從根本上與關係理論不一致。
歸根結底，您必須選擇對您的應用程式影響最小的解決方案。因此，在選擇資料庫設計之前，您需要知道如何查詢資料。無法選擇一種“最佳”解決方案，因為任何解決方案都可能最適合給定的應用程式。
2
537
@StoneHeart
我會一直使用 EAV 和 MVC 來到這裡。
@比爾·卡文
您在這裡提到的所有這些事情：
在我看來，根本不屬於資料庫，因為沒有任何資料庫能夠像應用程式的程式語言那樣在適當的層級上處理這些互動和需求。
在我看來，以這種方式使用資料庫就像用石頭錘釘子一樣。您可以用石頭來完成此操作，但您不應該使用更精確且專門為此類活動設計的錘子嗎？
可以透過對部分資料進行少量查詢並使用應用程式將其處理為表格佈局來解決此問題。即使您有 600GB 的產品數據，如果您需要此表中每一行的數據，也可以批量處理它。
進一步如果您想提高查詢的效能，您可以選擇某些操作，例如報告或全域文字搜尋並為其準備索引表，該索引表將儲存所需的資料並定期重新生成，假設每30 分鐘重新生成一次。
您甚至不需要擔心額外資料儲存的成本，因為它每天都變得越來越便宜。
如果您仍然關心應用程式執行的操作的效能，您始終可以使用 Erlang、C 、Go 語言來預處理數據，然後在主應用程式中進一步處理最佳化後的資料。 p>
您至少有以下五個選項來對您所描述的類型層次結構進行建模：
單表繼承：一個表格適用於所有產品類型，有足夠的欄位儲存所有類型的所有屬性。這意味著很多列，其中大多數在任何給定行上都是 NULL。
類別表繼承：一張產品表，儲存所有產品共有的屬性類型。然後每種產品類型一個表，儲存特定於該產品類型的屬性。
具體表繼承：沒有通用產品屬性的表。相反，每種產品類型一張表，儲存常見產品屬性和產品特定屬性。
序列化 LOB：一個產品表，儲存所有產品類型通用的屬性。一個額外的欄位以 XML、YAML、JSON 或某種其他格式儲存半結構化資料的 BLOB。此 BLOB 可讓您儲存特定於每種產品類型的屬性。您可以使用奇特的設計模式來描述這一點，例如 Facade 和 Memento。但無論如何，您都無法在 SQL 中輕鬆查詢大量屬性；您必須將整個 blob 提取回應用程式並在那裡進行排序。
Entity-Attribute-Value：一張產品表，以及一張將屬性旋轉到行而不是列的表。就關係範式而言，EAV 並不是一個有效的設計，但仍然有很多人使用它。這就是另一個答案提到的「屬性模式」。請參閱 StackOverflow 上使用 eav 標記 的其他問題，以了解一些陷阱。
我在簡報可擴展資料建模中寫了更多相關內容。
關於 EAV 的其他想法：雖然很多人似乎喜歡 EAV，但我不喜歡。這似乎是最靈活的解決方案，因此也是最好的解決方案。但是，請記住這句格言 TANSTAAFL。以下是 EAV 的一些缺點：
NOT NULL）。JOIN。EAV 的靈活性程度需要您在其他方面做出犧牲，這可能會使您的程式碼比以更傳統的方式解決原始問題更複雜（或更糟）。
並且在大多數情況下，沒有必要具有這種程度的靈活性。在OP關於產品類型的問題中，為每個產品類型建立一個用於產品特定屬性的表格要簡單得多，因此至少對於相同產品類型的條目強制執行一些一致的結構。
只有當必須允許每一行可能有一組不同的屬性時，我才會使用 EAV。當您的產品類型有限時，EAV 就顯得有些過分了。類別表繼承將是我的第一選擇。
2019 年更新：我越多看到人們使用 JSON 作為「許多自訂屬性」問題的解決方案，我就越不喜歡該解決方案。即使使用特殊的 JSON 函數，它也会使查询变得过于复杂> 來支援他們。與儲存在普通的行和列中相比，儲存 JSON 文件需要更多的儲存空間。
基本上，這些解決方案在關聯式資料庫中都不是簡單或有效的。擁有「可變屬性」的整個想法從根本上與關係理論不一致。
歸根結底，您必須選擇對您的應用程式影響最小的解決方案。因此，在選擇資料庫設計之前，您需要知道如何查詢資料。無法選擇一種“最佳”解決方案，因為任何解決方案都可能最適合給定的應用程式。