EAV（Entitty-Attribute-Value）模式是一种用于解决数据库设计中可扩展性问题的方法，尤其适用于属性不固定的场景。它通过实体、属性和值三个字段构成关系表，允许在不修改表结构的情况下添加新的属性。然而，EAV模式也存在数据逻辑一体性被分割、查询效率降低以及数据类型统一带来的计算不便等缺点。为克服这些问题，可以利用数据库的高级特性，如非结构化数据类型，或者考虑使用NoSQL存储。在存储空间有限的情况下，可以通过压缩数据或冗余关键字段来改善索引和类型管理。
数据库的设计一般都是面向业务的的，这样能够提供最直接的建模，一般也能提供更快的性能。关系型数据库需要在建库时就固定库的结构，有哪些表，有哪些字段，字段的类型…这种”提前确定“在刻画现实世界的时候会存在一些蹩脚的地方, 现实世界有些事物是无法提前确定的，通过使用EAV模式，可以在关系型库上设计出灵活可扩展的表结构，解决这种无法”提前确定“，引出Entitty-Atribute-Value(EAV)模式的一个经典案例就是医学临床记录的存储。
临床记录多种多样，有数不尽的指标，各个指标的值也不尽相同，血压，心率，咳嗽？显然是不同的指标，有不同的值。以二维表形式组织数据逻辑结构的关系表怎么表示？不断扩充列？显然是不现实的，最主要的原因是可以预见表要被经常变更，上层程序需要频繁需要修改，其次也可以想象到在一行中，大部分列都是空值，无数据；关系表本身是面向行记录的，多一条数据多一行，利用这个特性，把指标扩充在行上？更不现实，在与关系型表的模式格格不入的同时，加一个病人的临床记录岂不是还要加列？数据在逻辑上按行组织是最符合常人的习惯的，落到存储上时可以按数据逻辑进行行存储或是转置张表进行列存储，这两种存储方式分别在OLTS和OLAS领域有自己的优势，但这是数据的存储方式，和数据的逻辑存储形式不是一回事。想一张表实现灵活的，可扩展临床资料存储，每个病人一条临床数据看来不易。
一个病人的临床记录如果通过多条数据来分别存储，则可利用到关系表行记录特性，实现可扩展，这就是EAV模式，EAV抽象出Entitty-Atribute-Value的关系形成一张EAV表，至少有3个字
最低0.47元/天 解锁文章
994
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
