EAV模型如何适应业务变化

EAV模型适应业务变化的核心机制

• 通过“实体-属性-值”的三层结构，把原本固定的列转换为可配置的“属性定义”，业务新增或调整属性时，只需在属性元数据层变更，无需DDL改表，即可让新属性立即生效。典型结构包含：实体表（Entity）、属性表（Attribute：名称、数据类型、校验规则、是否必填等）、值表（Value：实体ID、属性ID、值）。该模型尤其适合用户自定义字段、稀疏数据、频繁变更的数据结构等场景。

变更流程与治理

• 属性定义与版本化：在属性表中新增或调整属性（如名称、类型、校验、展示顺序），并采用版本/生效时间管理，保证历史数据可追溯与回滚。
• 元数据驱动UI与校验：前端表单、列表与校验规则由属性元数据自动生成，新增属性即可自动获得输入控件、必填/正则/范围校验与字典联动，减少业务代码改动。
• 数据迁移与回填：对历史存量数据按新属性进行默认值回填/迁移脚本；必要时分阶段上线，避免一次性大改。
• 权限与审计：对属性增删改进行权限控制与操作审计，保障变更可控与合规。
• 低代码协同：在低代码平台中，属性管理、类型选择、数据输入与展示均可通过配置完成，进一步降低对底层代码的依赖。

查询与性能的应对

• 类型分表存储：避免“全部转字符串”带来的类型与索引问题，按数据类型拆分为多个值表，如eav_entity_int / eav_entity_varchar / eav_entity_text / eav_entity_decimal / eav_entity_datetime，查询与比较可直接利用原生类型索引。
• 索引与覆盖索引：在值表上建立**(entity_id, attribute_id)** 联合索引，必要时增加包含列或函数索引以减少回表；对范围/排序场景使用合适的索引类型。
• 查询重写与物化：将多属性查询改写为键值对集合的交/并/差逻辑，或使用存储过程/视图封装；对复杂检索引入**搜索引擎（如Solr）**建立文档索引，实现快速聚合与全文检索。
• 混合存储：将固定字段留在关系型表，将动态字段放入MongoDB等文档库，兼顾类型安全与查询性能，适合高并发与灵活扩展的业务。

数据完整性与约束

• 应用层校验与元数据约束：在Attribute层定义数据类型、必填、唯一性、取值范围/字典，在Service层统一校验，必要时借助AOP/校验框架保证一致性。
• 唯一性与条件唯一：通过唯一索引与部分索引（如 PostgreSQL 的 UNIQUE WHERE）实现“某类实体的某属性值唯一”等业务规则。
• 外键与级联：值表对实体表/属性表使用外键，结合软删除与级联策略减少脏数据与孤儿记录。
• 事务与幂等：属性变更与数据写入使用事务保证一致性；对高频写入提供幂等与重试机制。

何时采用或避免EAV

• 更适合的场景：属性集合庞大且稀疏、频繁变更、存在用户自定义字段，或需要跨类型/跨分类的灵活扩展（如电商商品、医疗记录、表单/低代码平台）。
• 不适合的场景：以强事务、复杂查询/报表、严格一致性为主的业务，或属性集合相对稳定、查询模式可预期的场景，优先采用固定列或JSON/文档方案。
• 折中方案：采用混合模型（固定列 + EAV/JSON），以固定列承载核心高频字段，将扩展字段放入EAV或文档库，既保留灵活性又兼顾性能与约束。