數據庫模型和性能

Question

我正在使用自建的數據庫模型。此模型是爲網店應用程序構建的。這是它的樣子：

首先，我有一個表爲我的產品。這包含只喜歡ID和articlenr通用數據，對所有的產品屬性（如名稱，價格等），我做了每類單獨的表，所以我有以下表格：

product_att_varchar 
product_att_decimal 
product_att_int 
product_att_select 
product_att_text 
product_att_date 

這些表相關由關係表procuct_att_relational

我的問題是這種結構的性能，如果我想要一個特定的產品的所有屬性，如果必須使用這麼多的連接，它會減慢非常多。

有沒有人有這個解決方案？

謝謝

Answer 1

人們不斷回到這種模式，因爲他們認爲它是「靈活的」。那麼，我想是的，但這種靈活性帶來了巨大的代價：每個更新和每個查詢都很慢並且很複雜。 Quassnoi提到如果屬性是稀疏的，即大多數實體實例只有可能屬性的一小部分，這可以節省空間。這是真的，但另一方面是，如果它不稀疏，則需要更多的空間，因爲現在除了值之外，還必須爲屬性名或代碼存儲每個屬性，此外還需要重複某種鍵來識別每個屬性的邏輯實體實例。

我能想到的唯一一次這將是一個好主意，如果屬性列表需要動態更新，也就是說，用戶需要能夠決定創建一個新的屬性，只要他喜歡。但那麼系統會用這個屬性做什麼？如果你只是希望用戶能夠輸入它，然後稍後檢索他輸入的內容，就夠簡單了。但是它會以任何方式影響處理嗎？就像，如果用戶決定添加「清倉代碼」，您的程序將如何知道這會如何影響銷售價格？當然可以這樣做：您可以在其他屏幕上輸入用戶輸入的數據，以某種方式描述每個字段如何影響定價或重新排序等等。但是這會增加更多的複雜性。

所以我簡短的回答是：除非你有一個非常專業的要求，不要這樣做。如果您試圖建立一個數據庫來描述您銷售的物品，例如描述，價格和數量等，然後創建一個包含描述，價格和數量等字段的表格。生活已經夠艱難，不會爲了讓事情變得更難而走出困境。

Answer 2

我沒有看到有任何理由將這些屬性移出產品表。如果你這樣做了，那會是一回事，因爲你有一些數據表明存在問題，但看起來你認爲「這會更好」。你爲什麼以這種方式做到這一點？

如果你這樣做是因爲它是爲你生成的，我建議放棄該生成器。

Answer 3

該模型被稱爲EAV（實體屬性值），有其缺點和優點。

好處是它非常靈活，可以輕鬆擴展。如果您有非常多的非常稀疏的屬性，在設計時（例如，用戶提供的）無法預測屬性，或者很少使用的屬性，它可能會很有用。

缺點是性能和無法在同一時間索引幾個屬性。但是，如果您的數據庫系統允許索引視圖（如SQL Server）或多個表的集羣存儲（如Oracle），那麼通過使用這些技術可以提高性能。

但是，將所有屬性存儲在一個記錄中仍然會更快。