首页 > 数据库 > 其他综合 >

数据库设计之EAV(实体、属性、值)

2014-09-27

有这么一个业务,用于客户记录每天做的事情,由于是非常专业的事情,需要专业的记录本,这种记录本有20多种。实际工作中也是有20多样的记录本,记录本的& 26684;式每隔一年会有点变动。如何进行数据库设

有这么一个业务,用于客户记录每天做的事情,由于是非常专业的事情,需要专业的记录本,这种记录本有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,你必须承担我上述说的风险。

相关文章
最新文章
热点推荐