EAV模型如何解决属性扩展

EAV（Entity–Attribute–Value，实体–属性–值）模型是一种用来解决对象属性高度动态、稀疏、易扩展的数据建模方式。它常用于电商商品属性、医疗病历、CMS 字段、配置系统等场景。

下面从「为什么用 EAV」「EAV 怎么解决扩展」「典型结构」「优缺点与改进方案」几个层面说明。

一、传统模型在属性扩展上的问题

1. 宽表模型（固定列）

product (
  id,
  name,
  price,
  color,
  size,
  weight,
  ...
)

问题：

• 新增属性 → 改表结构（DDL）
• 不同类目属性差异大 → 大量 NULL 列
• 属性爆炸 → 表极宽、性能差

二、EAV 如何解决属性扩展

核心思想

把“列”变成“行”

不再是：

一个实体 = 一行多列

而是：

一个实体 = 多行（属性名 + 属性值）

三、EAV 典型数据结构

1. 实体表（Entity）

entity (
  id,
  type,
  name
)

2. 属性表（Attribute）

attribute (
  id,
  name,
  data_type  -- string / int / datetime
)

3. 值表（Value）

entity_attribute_value (
  entity_id,
  attribute_id,
  value
)

示例数据

entity_id=1 (手机)
attribute_id=10 (品牌) => 苹果
attribute_id=11 (内存) => 256GB
attribute_id=12 (颜色) => 黑色

✅ 新增属性 = 插入数据，不动表结构

四、EAV 如何解决不同扩展场景

1. 类目不同，属性不同

• 手机：内存、屏幕
• 衣服：尺码、材质

→ 只存需要的属性，无 NULL 浪费

2. 后期频繁加字段

• 新业务：加“保修期”
• 传统：ALTER TABLE
• EAV：INSERT attribute

3. 用户自定义字段

• 用户自己加“备注A”
• EAV 天然支持

五、EAV 的代价与问题

1. 查询复杂

SELECT ...
FROM eav
PIVOT (...)

或多次 JOIN

2. 类型不安全

• value 通常是 STRING
• 需额外校验 / 转换

3. 索引困难

• 按属性查询慢
• 全表扫描风险

六、常见优化方案

✅ 1. 分类型 EAV

• 不同类型 → 不同 EAV 表
• 或按 data_type 分表

✅ 2. EAV + 宽表混合（推荐）

• 通用字段：宽表
• 扩展字段：EAV

product (id, name, price)  -- 稳定字段
product_attr (product_id, attr_id, value)

✅ 3. JSON / 文档字段（现代替代）

product (
  id,
  base_info JSON
)

• MySQL / PostgreSQL 支持索引
• 比纯 EAV 更简单

✅ 4. 物化视图 / 冗余表

• 后台异步生成“宽表快照”
• 查询快，写入慢

七、一句话总结

EAV 通过“属性行化”，用数据代替表结构，从而在不改数据库 schema 的情况下实现无限属性扩展，但代价是查询复杂和性能挑战，通常应与宽表或 JSON 混合使用。

如果你愿意，我也可以：

• 画一张 EAV vs 宽表对比图
• 给你一个电商商品 EAV 实战设计
• 用某个数据库（MySQL / PG）写示例 SQL