良好的數據庫設計，可變數量的屬性

我想創建一個包含設備列表的數據庫。所有的設備都有一些共同的屬性（例如製造商，型號＃，序列號等），然後還有其他屬性是特定於某個設備的（即，一個調制解調器將有一個訪問＃，而太陽能電池板將具有輸出容量）。我不知道如何用良好的數據庫設計原則來表示這些不斷變化的屬性，我嘗試過在網上搜索，但我並不完全知道要搜索什麼。良好的數據庫設計，可變數量的屬性

我拿出他們以下可能的解決方案和我最初的想法：

與每一個可能的屬性的一個大表，只是把空的地方是不適用的。顯然這有一些缺陷。
爲每種設備類型都有一個單獨的表格。這似乎可能是一個噩夢使用，如果我想打印所有設備的列表，我怎麼知道哪些表查找？
擁有一個表格，其中包含通用屬性和其他用於存儲額外屬性的外鍵訪問的每種設備類型的表格。我大概可以完成這項工作，但這會很麻煩，只是覺得不是一個很好的解決方案。
實體屬性值類型模型。只是看起來不適合我想要做的事情。

我沒有很多與數據庫，所以我的學習經驗，因爲我去這裏，關於這個問題的任何鏈接或「必讀」數據庫設計篇，將不勝感激。謝謝！

編輯：首先，我發現我需要谷歌「繼承映射」，這可能會幫助其他人有類似的問題。爲了解決這個問題，我最終使用了＃2和＃3的混合。實際上它非常簡單，運行良好，並且解決了添加額外設備類型而沒有EAV複雜性的問題。感謝所有的意見和建議！

來源

2012-07-21 neurotik

chek在下面的帖子中的答案：http://stackoverflow.com/questions/870808/entity-attribute-value-database-vs-strict-relational-model-ecommerce-question – 2012-07-21 04:11:21

這篇文章與一些其他文章相矛盾我閱讀說應該避免EAV，想到任何人？ – neurotik 2012-07-21 04:37:24

選項1,2和3有一個非常嚴重的缺陷：當有人想出新屬性時，必須修改基礎表模式。在選項1的情況下，由於可能引入新的設備類型，這個問題變得更加複雜。你有多確定一組屬性是否始終保持固定？你有多幸福會停工或告訴客戶不，你不能有新的屬性？

如果您很有可能對常見屬性進行查詢，您可能會嘗試使用3和4的混合，並且在屬性類型而非設備類型上進行分割時使用2的短劃線，這看起來更不穩定。如果我理解正確，選項4是選項1的常規形式版本，它解決了其所有固有問題（稀疏性和脆性）。

INVENTORY(id*, model, manufacturer, serial) 
ATTRIBUTE(id*, name, type, description) 
INVENTORY_FACT_STRING(inv_id*, attr_id*, value) 
INVENTORY_FACT_NUMBER(inv_id*, attr_id*, value) 
INVENTORY_FACT_LIST_STRING(inv_id*, attr_id*, ordinal*, value)

等

來源

2012-07-21 04:10:13

新設備的推出是確定的，有人希望事後添加屬性是不太可能的，但可能的。中斷不是問題，但是說新的屬性不能被添加是不可能的，因爲需要添加新的設備，並且我不能確定目前的屬性將覆蓋所有未來的情況。 – neurotik 2012-07-21 04:27:01

這聽起來很像EAV。不要害怕！ – 2012-07-21 04:46:34

哇，這裏所有人都支持EAV。不是我所期望的，令人驚訝的是，研究開始時的一些負面文章如何真的讓你脫離軌道！我會放棄它。感謝大家！ – neurotik 2012-07-21 05:12:02

這對於任何SQL數據庫都很難解決。 MySQL沒有很好的答案。

1）工作，你可以爲重要的設備類型添加一些視圖。它減少了連接的數量並允許在每個字段上進行查詢和索引。

2）您可以在視圖中使用union all查詢。 PostgreSQL和Informix有表繼承。

3）這通常是一種實現選擇。再次，您可以使用視圖來進行連接。 4）PostgreSQL，Informix，Oracle，IBM DB2和MS SQL Server都支持XML數據類型來實現值對。

在更高層次上，您可以開發XML設備的元模型。然後你可以使用這個模型來生成模式SQL查詢和CRUD代碼。

來源

2012-07-21 04:07:45

我認爲你面對一個常規數據庫正常化。你需要一個像表：

Items -> Id, Name, Model, Brand Id 
Brands -> Id, Name 
Attribute Names -> id, name 
Attribute Mappings -> Id, Names Id, Items Id, Attribute Description

在情況下，如果有一個以上的Attribue，在屬性表列表中，然後和準用產品編號等，儘量拿出第三規範化形式

Database Normalization

來源

2012-07-21 04:13:34 Andrew

這是我提到的EAV模型，不是嗎？ – neurotik 2012-07-21 04:35:59

我不認爲這是「常規」。 – johnny 2018-03-05 16:13:04

替代品1，2和3由Martin Fowler在他的一本書和他的網站上概述。

Single Table Inheritance (option 1)

Concrete Table Inheritance (option 2, sort of)

Class Table inheritance (option 3)

我的選擇是選項3.每個人都有對事物的總體方案的地方。

EAV可以在飛行中很好地添加新的屬性。但是，當將數據轉化爲有用的信息時，EAV數據庫可能是一場噩夢。