数据库设计之EAV(实体、属性、值)
有这么一个业务，用于客户记录每天做的事情，由于是非常专业的事情，需要专业的记录本，这种记录本有20多种。实际工作中也是有20多样的记录本，记录本的格式每隔一年会有点变动。如何进行数据库设计？
有两种方案：
1.为每个记录本建单独的表。
2.动态表，把记录本的属性放入到字典中，记录本的内容以实体、属性、值的形式存储。
--存储记录本的格式
createtable note_dictionary
(
dictionary_id number,
dictionary_type varchar2(50),--记录本的类型，就是那20多种记录本
dictionary_name varchar2(200)--记录本中的名称
);
--存储记录本的内容
createtable note_content
(
content_id number,
note_id number, --具体的一个记录本的id
dictionary_id number,--记录本中字段的id
content varchar2(1000)--字段的内容
);
如果只是从开发人员的角度来看，会选择方案2。方案1工作量多大啊，每次改记录本的格式都要做调整，方案2都有扩展型啊，调整格式都不需要改代码。毫无争议的选择方案2。
选择方案2后，会牺牲很多传统数据库设计代码的好处，如果记录本之前是有关系的，实现会变得更复杂。
1.记录本中的字段类型无法制定，如果是Date和number，只能用varchar2表示。关于类型选择不正确会造成什么问题，在我之前的blog中有写到。再者统计也可能出现问题，即使你前段控制的再好，也不能保证最后到数据库中后的是正确的，这个问题看到的太多了。
2.不能加not null的约束和默认值。
3.如果要查某个记录本的a字段，需要先去找字典，然后再到内容表中去找，不直观，涉及到后期维护数据较麻烦。
4.如果记录本之间是有关系，要建立关联关系，需要再加表，实现很复杂。
5.在一段时间后内容表会变得非常之笨重，系统中就属它数据量大。
6.我以前维护过这种设计代码，因为是通用的，有时候改了这里，也不知道会不会影响其他的地方。Java代码中使用了反射，debug很难调试，问题难定位。总体来说，有一种身不如死的感觉。
上面的模块我倾向选择方案1，开发工作量大一点，但维护工作量小，数据更加精准。那是不是一定不要用方案2呢？也不是，业务，业务，还是业务，如果你的单据不需要统计分析，数据量也不大，单据种类非常多，开发人员水平很高，你想要做到记录本可配置，那可以选择方案2。如果你不详细了解业务的情况下，坚持选择方案2，你必须承担我上述说的风险。
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
