EAV模型（实体-属性-值）的设计和低代码的处理方案（1）

一般我们在开发的时候，习惯上使用常规的关系型数据库来设计数据库表，对于一些业务表的字段比较固定的场景，是一种非常不错的选择，而且查询的时候，由于是基于固定的表字段进行查询，性能基本上是最优的。不过有一些场景下，业务信息的经常变化，使用常规的关系型数据库来创建表字段、删除字段的模式，肯定不是合适的处理方案，因此可能会进入JSON数据存储的方式，而现今很多关系型数据库也都支持JSON的存储和子查询处理，不过JSON的检索还是比较麻烦，而且对于复杂的子查询，性能据说也好不到哪里。而非关系型数据库的NoSQL数据库（MongoDB数据库），它的产生就是为了解决大规模数据集合多重数据种类带来的挑战。结合关系型数据库的熟练使用、性能优势和MongoDB数据库的弹性化文档处理特点，我对EAV模型（实体-属性-值）的设计和低代码的处理方案提供一个实用的思路供参考。

1、数据库 EAV 模型设计

如果我们要做一个电商的商品管理，我们先卖一些衣服，需要管理衣服的尺码、颜色、款式等信息；有一天需要卖电脑了，电脑需要主板、CPU、显卡、内存、硬盘、散热等信息；过几天又需要卖手机了，手机有颜色、版本、存储容量、套餐类型等等信息。数据库的频繁更改，可能会导致开发的复杂度增加，说不准要重新处理。

如果我们每次新增商品，需要支持不同的信息的话就不停的加字段。这样会导致很多问题：

1、实现成本高，每次可能需要重新修改底层代码，界面布局及相关处理等

2、性能越来越差，每次增加的字段，随着复杂性越来越大，字段越来越多，导致性能急剧下降。

3、维护越来越难，没有好的系统规划，就如在沙堆上建设豪华城堡，随着时间的推移，越来越难维护。

还有一种是采用JSON数据存储方案，对于扩展的数据，可以统一存储在某个JSON里面，这样设计的扩展字段，可以有效屏蔽一些复杂度，并提高弹性化。如可以把尺码、颜色、款色、主板、CPU、显卡、内存等等都放到 JSON 里。

不过这样JSON数据存储方案，对于更新和条件查询来说，性能是比较差的，随着数据量和复杂度的增加，这种响应效果肯定不如意的，对于大数据的处理，这种处理肯定是灾难性的。

EAV（Entity-Attribute-Value）模型是一种灵活的数据库设计方法，特别适合存储具有可变属性的实体。

Entity：实体，代表一个业务对象，比如上面的例子里的商品。

Attribute：对象的属性，属性并不是作为实体单独的一列来进行存放，而是存储在一组单独的数据库表中。

Value：指特定属性所关联的值。

在电商商品管理系统中，商品的属性可能会变化，因此EAV模型是一个合适的选择。每个实体都有唯一的标识符，每个实体都可以有多个属性与之关联，每个属性都有唯一的标识符，每个属性都可以具有多个值。

以下是一个简单的EAV模型设计示例：

实体表（Entity Table）：

这里的实体是指商品。可能这里用实体类型表述更准确。

属性表（Attribute Table）：

这里的属性是指商品的特征，例如颜色、尺寸等。

值表（Value Table）：

这里存储了实体和属性的关联，以及具体的属性值。

这样设计的好处在于，你可以灵活地添加新的属性，而无需修改数据库结构。然而，EAV模型也有一些缺点，例如查询可能会更加复杂，因为需要在值表中进行属性值的连接。

2、优化的EAV模型

对于上面属性值的存储，统一都采用字符串的方式来存储，这样对于类型的处理和空间节约肯定是不好的，因此我们需要进行优化，根据不同的类型存储在不同的表上。

上面属性值没有类型限制，都是 VARCHAR 的，对数据库不友好，会导致内存浪费，而且存取都需要进行数据格式转换。对存储为字符串的值创建的索引不允许针对数值型和日期型的搜索范围优化，这是采用混合数据类型的键-值对描述数据的公共问题。

我们对属性值表基于数据类型进行分割，每个不同的数据类型拆为一个单独的表，同时通过属性表（Attribute）添加类型决定去哪里存取数据。

我们可以借鉴magento的eav模型，它是EAV设计的最优参考了。Magento 2中的EAV属性类型有下面这些表：

eav_entity_int
eav_entity_varchar
eav_entity_text
eav_entity_decimal
eav_entity_datetime

这5种属性类型就相当于字段类型，一般关系型数据库类型是通用的。

int 对应字段的int类型
varchar 对应字段的varchar类型
text 对应字段的text类型
decimal 对应字段的decimal类型
datetime对应字段的datetime类型

这样分别不同类型的数据进行不同表的存储了。

其他的属性类似的处理即可。

参考下eav的设计图，了解一下各个表之间的关系。

以及magento的eav模型设计图，复杂的令人抓狂。

3、NoSQL数据库的登场

使用EAV（Entity-Attribute-Value）模式来存储完整的数据结构信息以及NoSQL数据库来存储完整的记录是一种灵活的方法，特别适用于需要存储动态结构数据的场景。

EAV的常规关系型数据库表存储常规的设计表，如实体类型、属性定义、属性值（多个）表的相关信息，而利用MongoDB数据库的大数据处理灵活性和高性能的响应，能够存储我们实际变化的文档信息。在检索的时候，并提供了常规关系型数据库的联合查询、JSON查询无法得到的灵活性和高性能。好马配好鞍，双剑合璧，简直完美。

在介绍实现我们的EAV模型设计的过程前，我们先来看看实际的界面效果

1）实体类型表和属性定义处理