庫存控制的'EAV'或'類/具體表繼承'數據庫的設計

Question

我正在開發一個建築項目的庫存控制系統。店主負責添加新的庫存並將其分發/退回給員工。項目（因此它們的屬性）將會變化很大。例如鋼鐵廠，服裝，工廠/機械，工具等。

我的問題是要去Class/Concrete Table Inheritance或基於EAV的模式。我不知道項目將具有什麼屬性，因此推測類/具體表繼承方法會要求最終用戶向數據庫添加新表（這是可能的嗎？）。

請參閱我建議的EAV schema。這會是一個合理的解決方案嗎？我認爲我說得很對，要確定一個股票的項目，有必要在'EV'表上查詢時執行多個自我加入。

N.B.使用PHP，MySQL和Zend Framework開發。

Answer 1

• 如果屬性的變化是少之又少，去表繼承，但對架構的更改應該由自己或DBA來完成。基於用戶輸入以編程方式修改您的模式似乎是一個壞主意。

• 如果屬性的變化是相當普遍的，可以考慮使用document-oriented database像MongoDB或CouchDB。

• 如果屬性更改很常見，而且僅限於關係數據庫，請使用EAV。

Answer 2

我會避免EAV，除非我正在建立一個有成千上萬種產品的醫療信息庫。類表繼承是一個適當的解決方案，在運行時改變模式並不是什麼壞主意。

假設你正在建立一個網上商店，你有不同的產品具有不同的屬性。通常，產品正在使用一組屬性。通過使用Class Table Inheritance模式，您可以爲每個產品組使用一個表，繼承具有常見產品屬性的公共表。當需要一個新的屬性，你有兩個選擇：

• 改變安放臺和帶有屬性名稱
• 創建一個新的集（即新表）與新列添加一個新的列並設置當前產品設置爲繼承新產品，從而添加新的屬性。

在運行時更改表可能確實會導致問題，因爲在更改過程中發生鎖定。然而，從MySQL 5.6開始，程序員可以指定一個LOCK類型，例如LOCK = NONE，也可以ALTER ONLINE | OFFLINE。顯然，DB供應商正在朝這個方向努力，以便在運行期間進行數據庫更改。

表鎖定問題也可以避免/最小化。鎖定問題通常發生在改變巨大的表格（即100k +記錄）時。但是，繼承允許分配不同集合中的產品，因此每個表的記錄數量相對較少。

例如，如果我們有10種不同類型的產品，我們有10個不同的表格。假設我們每種類型都有10000個產品，這意味着我們有超過10萬個產品，但是在一個集合中添加一個新屬性實際上只會在具有10000個行的表中添加一個新列。在具有10k行的表中添加新列的時間會少於一秒，因此在處理類表時繼續改變數據庫模式繼承真的是個壞主意？

我很樂意在這裏聽到更多意見。多謝你們。