一般情况下，我们在开发过程中习惯使用传统的关系型数据库设计数据库表。对于业务表字段比较固定的情况来说，这是一个不错的选择。查询时，基于固定表字段进行查询通常具有最佳性能。然而，对于业务信息经常变化的情况，使用传统的关系型数据库来创建表字段、删除字段的模式显然不是合适的处理方案。在这种情况下，可能会考虑采用JSON数据存储的方式。现今，许多关系型数据库都支持JSON的存储和子查询处理。尽管JSON的检索仍然比较麻烦，对于复杂的子查询，据说性能也不佳。因此，非关系型数据库的NoSQL数据库（如MongoDB数据库）的出现是为了解决大规模数据集合和多重数据种类带来的挑战。结合关系型数据库的熟练使用、性能优势和MongoDB数据库的弹性化文档处理特点，我们可以为EAV模型（实体-属性-值）的设计和低代码的处理方案提供一个实用的思路供参考。

1、数据库 EAV 模型设计

在电商商品管理系统中，商品的属性可能会发生变化，因此EAV模型是一个合适的选择。每个实体都有唯一的标识符，每个实体都可以有多个属性与之关联，每个属性都有唯一的标识符，每个属性都可以具有多个值。EAV（Entity-Attribute-Value）模型是一种灵活的数据库设计方法，特别适合存储具有可变属性的实体。实体代表一个业务对象，如商品；属性指对象的特征，例如颜色、尺寸等；值指特定属性所关联的值。这种设计方式的好处在于，可以灵活地添加新的属性，而无需修改数据库结构。然而，EAV模型也有一些缺点，例如查询可能会更加复杂，因为需要在值表中进行属性值的连接。

2、优化的EAV模型

对于属性值的存储，统一采用字符串的方式来存储，这对于类型的处理和空间节约不利，因此我们需要进行优化，根据不同的类型存储在不同的表上。我们对属性值表基于数据类型进行分割，每个不同的数据类型拆为一个单独的表，同时通过属性表（Attribute）添加类型决定去哪里存取数据。我们可以借鉴Magento的EAV模型，它是EAV设计的最优参考了。Magento 2中的EAV属性类型有五种表，分别对应字段的int类型、varchar类型、text类型、decimal类型和datetime类型。这样分别不同类型的数据进行不同表的存储了。

3、NoSQL数据库的登场

使用EAV（Entity-Attribute-Value）模式来存储完整的数据结构信息以及NoSQL数据库来存储完整的记录是一种灵活的方法，特别适用于需要存储动态结构数据的场景。EAV的常规关系型数据库表存储常规的设计表，如实体类型、属性定义、属性值（多个）表的相关信息，而利用MongoDB数据库的大数据处理灵活性和高性能的响应，能够存储我们实际变化的文档信息。在检索的时候，并提供了常规关系型数据库的联合查询、JSON查询无法得到的灵活性和高性能。