数据库的设计一般都是面向业务的的,这样能够提供最直接的建模,一般也能提供更快的性能。关系型数据库需要在建库时就固定库的结构,有哪些表,有哪些字段,字段的类型…这种”提前确定“在刻画现实世界的时候会存在一些蹩脚的地方, 现实世界有些事物是无法提前确定的,通过使用EAV模式,可以在关系型库上设计出灵活可扩展的表结构,解决这种无法”提前确定“,引出Entitty-Atribute-Value(EAV)模式的一个经典案例就是医学临床记录的存储。
临床记录多种多样,有数不尽的指标,各个指标的值也不尽相同,血压,心率,咳嗽?显然是不同的指标,有不同的值。以二维表形式组织数据逻辑结构的关系表怎么表示?不断扩充列?显然是不现实的,最主要的原因是可以预见表要被经常变更,上层程序需要频繁需要修改,其次也可以想象到在一行中,大部分列都是空值,无数据;关系表本身是面向行记录的,多一条数据多一行,利用这个特性,把指标扩充在行上?更不现实,在与关系型表的模式格格不入的同时,加一个病人的临床记录岂不是还要加列?数据在逻辑上按行组织是最符合常人的习惯的,落到存储上时可以按数据逻辑进行行存储或是转置张表进行列存储,这两种存储方式分别在OLTS和OLAS领域有自己的优势,但这是数据的存储方式,和数据的逻辑存储形式不是一回事。想一张表实现灵活的,可扩展临床资料存储,每个病人一条临床数据看来不易。
一个病人的临床记录如果通过多条数据来分别存储,则可利用到关系表行记录特性,实现可扩展,这就是EAV模式,EAV抽象出Entitty-Atribute-Value的关系形成一张EAV表,至少有3个字