數據庫設計之EAV(實體、屬性、值)

    有這么一個業務，用于客戶記錄每天做的事情，由于是非常專業的事情，需要專業的記錄本，這種記錄本有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，你必須承擔我上述說的風險。

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈