產品屬性的數據庫模式

Question

因爲有很多人在尋找Products /Product Properties數據庫模式。我使用Ruby on Rails和（思考）Sphinx進行分面搜索。

要求：

• 添加新的產品類型和他們的選擇不應該需要改變使用獅身人面像
• 支持面搜索的數據庫架構。

解決我遇到：
（See Bill Karwin's answer）

選項1：單表繼承

不是一種選擇，真的。該表將包含許多列的方式。

選項2：類表繼承

Ruby on Rails的緩存在啓動時的數據庫模式，這意味着每當引入新類型的產品的重新啓動。如果您的產品目錄大小可能會有數百個表格。

方案3：序列LOB

殺敵能夠做面搜索，而不重應用程序邏輯。

方案4：實體 - 屬性 - 值

出於測試目的，EAV工作得很好。然而，它可能很快成爲一個爛攤子，維護地獄爲你添加更多選項（例如，當一個選項，增加價格或交貨時間）。

---

我應該選擇什麼樣的選擇？還有哪些其他解決方案？有沒有我忽視的銀彈（哈）？

Answer 1

國際海事組織，類表繼承和EAV與一些嚴重的限制組合將是最好的辦法。

EAVs就像毒品一樣：數量少，環境狹窄，可以是有益的;太多會殺了你。作爲模式的主要部分的EAV將會失敗。沒有問題。但是，如果您執行適當的限制，作爲良好數據庫模式的補充，它們可能會很有用。

與EAV的主要規則是，你可以永遠編寫一個查詢，其中包括'[AttributeCol] = 'Attribute'。換句話說，你永遠無法篩選，排序，在限制範圍內，也沒有任何地方的特定屬性的報表或表格。這僅僅是數據包可以在列表中的一個報告或屏幕上完全吐出。事實上，我看到人們實現此功能作爲XML列。

如果你能夠保持這個限制，那麼你可以將EAV結構的一類表繼承設計添加爲讓用戶一組屬性添加到產品僅用於存儲目的的一種手段。當他們想要使用某個屬性來執行任何具體的任務時，它必須成爲頭等列和所有必需的東西。

關鍵在執法。如果您覺得您不能合理執行或讓其他開發人員在使用EAV結構時強制實施此限制，那麼跳過它可能會有意義。但是，如果您可以強制執行此限制，則可以解決人們希望添加大量屬性僅用於存儲和跟蹤目的的問題。