數據庫設計：EAV選項？

這只是一個數據庫概念問題：以下EAV模型有哪些優缺點？數據庫設計：EAV選項？

模型1：

TABLE: attribute_value 
====================================== 
| id | fk_id | attribute | value  | 
====================================== 
| 1 | 10 | FName  | John  | 
| 2 | 10 | Lname  | Doe  | 
| 3 | 55 | FName  | Bob  | 
| 4 | 55 | Lname  | Smith  | 
--------------------------------------

模型2：

TABLE: attribute 
================== 
| id | attribute | 
================== 
| 1 | FName  | 
| 2 | Lname  | 
------------------ 

TABLE: value 
===================================== 
| id | attribute_id | fk_id | value | 
===================================== 
| 1 | 1   | 10 | John | 
| 2 | 2   | 10 | Doe | 
| 3 | 1   | 55 | Bob | 
| 4 | 2   | 55 | Smith | 
-------------------------------------

一個好處我與模型2看到的是attribute不包含重複。

來源

2011-08-11 StackOverflowNewbie

缺點：EAV真的很難優化。過了一段時間，您會遇到無法寫入的查詢，以至於無法正常工作。 – zerkms

雖然極簡主義如圖所示，Model2的屬性表將元數據的概念引入混合中，其中包含所有好處。 Model2還有其他優點，例如的性能增益與較小的行值（值表）相關，但我想關注元數據概念。

即使原樣 Model2的屬性表構成所有有效的存儲庫屬性（與模型1人會需要運行各種彙總查詢得到這樣的列表）。此外，和原樣，倉庫足以引進外鍵約束，以幫助保持數據集（與模型1人會需要存儲在屬性列中的值的驗證外在形式的完整性。

通過一些簡單的添加，屬性表可以變得可用於各種目的，一個多功能存儲庫中。例如，該表可以包括一些下面

信息的諸如每個屬性的顯示友好名稱
一些標誌印度（數值與字符串與日期等），用於區分處理/處理
存儲底層屬性的特定值表（模型只顯示一個表，但優化/縮放有時會提示分割表）
該屬性可以作爲其自己的列存儲在「Value」表中（這也是一種優化形式，實質上獲得了兩全其美的優點：EAV模型的模式的靈活性，但是性能傳統關係模型用於所有實體使用最多和/或最常見的屬性。
能夠重新命名屬性，而不會干擾主表。僅在元數據級別進行更改。
各種面向應用的語義。例如，應該提供特定屬性作爲基本與高級搜索字段之一的指示符。

概括地說，該屬性表變爲一個資源，其允許該應用程序是真正數據驅動（或者更準確地說，元數據驅動）。事實上，你可能也想在那裏屬於類型收集的各種實體的元數據，即一個實體表：它們是不同的實體類型，哪些屬性是允許該實體類型等

現在...做留意來自zerkms的意見，低於問題本身。儘管它的所有好處，EAV模型也帶來了它的缺點和挑戰的一部分，暗示了查詢的複雜性以及性能問題。然而，這些顧慮不應該使先驗EAV喪失資格：有很多使用EAV的方法是更好的方法。
假設EAV是選擇，那麼Model2，或者甚至稍微複雜一些的東西都明顯優於model1。

來源

2011-08-11 03:33:13 mjv

mjv - 模型2仍然被認爲是EAV？ – StackOverflowNewbie

@StackOverflowNewbie - 是的，最明確的。的關鍵概念，這使得它EAV的是，「主」表（「值」的模型中顯示錶）捆綁所有3元素：實體（fk_id），屬性（attribute_id）和值。該屬性恰好在[model]中的屬性列中顯示爲[數字] id，而不是某些文本，但是這個事實當然不會刪除設計的EAV-ness。 – mjv

對於Model 2，您可以在attribute_id上強加一個外鍵，並確保唯一定義的屬性可以輸入該表。

對於模型2，您可以更快地查詢以獲取具有某些屬性ID的值，因爲如果您創建外鍵（索引），查詢速度會更快。

來源

2011-08-11 03:08:09

在概念層面，這兩款車型幾乎是一樣的。您剛剛用ID號替換了字符串。就這樣。

至於外鍵去，你可以在模型1施加一個外鍵約束的「屬性」，如果你想。

至於利弊去，沒什麼EAV的這兩種實現之間沒有什麼區別。所有Bill Karwin's points適用於兩者。

來源

2011-08-11 09:12:34

數據庫設計：EAV選項？

回答

相關問題