数据库设计之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，你必须承担我上述说的风险。