跟大家講解下有關數據庫設計之EAV(實體、屬性、值)，相信小伙伴們對這個話題應該也很關注吧，現在就為小伙伴們說說數據庫設計之EAV(實體、屬性、值)，小編也收集到了有關數據庫設計之EAV(實體、屬性、值)的相關資料，希望大家看到了會喜歡。

有這么一個業務，用于客戶記錄每天做的事情，由于是非常專業的事情，需要專業的記錄本，這種記錄本有20多種。實際工作中也是有20多樣的記錄本，記錄本的式每隔一年會有點變動。如何進行數據庫設計？ 有兩種方案： 1.為每個記錄本建單獨的表。 2.動態表，把記

有這么一個業務，用于客戶記錄每天做的事情，由于是非常專業的事情，需要專業的記錄本，這種記錄本有20多種。實際工作中也是有20多樣的記錄本，記錄本的格式每隔一年會有點變動。如何進行數據庫設計？

有兩種方案：

1.為每個記錄本建單獨的表。

2.動態表，把記錄本的屬性放入到字典中，記錄本的內容以實體、屬性、值的形式存儲。

--存儲記錄本的格式

createtable note_dictionary

(

dictionary_idnumber,

dictionary_typevarchar2(50),--記錄本的類型，就是那20多種記錄本

dictionary_namevarchar2(200)--記錄本中的名稱

);

--存儲記錄本的內容

createtable note_content

(

content_idnumber,

note_id number,--具體的一個記錄本的id

dictionary_idnumber,--記錄本中字段的id

contentvarchar2(1000)--字段的內容

);

如果只是從開發人員的角度來看，會選擇方案2。方案1工作量多大啊，每次改記錄本的格式都要做調整，方案2都有擴展型啊，調整格式都不需要改代碼，區區2張表解決了20多張表的問題，多酷。毫無爭議的選擇方案2。

選擇方案2后，會犧牲很多傳統數據庫設計代碼的好處，如果記錄本之前是有關系的，實現會變得更復雜。

1.記錄本中的字段類型無法制定，如果是Date和number，只能用varchar2表示。關于類型選擇不正確會造成什么問題，在我之前的blog中有寫到。再者統計也可能出現問題，即使你前段控制的再好，也不能保證最后到數據庫中后的是正確的，這個問題看到的太多了。

2.不能加not null的約束和默認值。

3.如果要查某個記錄本的a字段，需要先去找字典，然后再到內容表中去找，不直觀，涉及到后期維護數據較麻煩。

4.如果記錄本之間是有關系，要建立關聯關系，需要再加表，實現很復雜。

5.在一段時間后內容表會變得非常之笨重，系統中就屬它數據量大。

6.我以前維護過這種設計代碼，因為是通用的，有時候改了這里，也不知道會不會影響其他的地方。Java代碼中使用了反射，debug很難調試，問題難定位。總體來說，有一種身不如死的感覺。

7.所有復雜一點的查詢都會變得復雜。

上面的模塊我傾向選擇方案1，開發工作量大一點，但維護工作量小，數據更加精準。那是不是一定不要用方案2呢？也不是，業務，業務，還是業務，如果你的單據不需要統計分析，數據量也不大，單據種類非常多，開發人員水平很高，你想要做到記錄本可配置，那可以選擇方案2。如果你不詳細了解業務的情況下，堅持選擇方案2，你必須承擔我上述說的風險。

來源：php中文網