怎样设计EAV模型

EAV（Entity–Attribute–Value，实体–属性–值）模型是一种用来存储高度动态、稀疏、属性不固定的数据的数据库设计模式，常用于电商商品参数、医疗病历、自定义表单等场景。

下面从核心思想 → 表结构设计 → 常见变体 → 优缺点 → 设计建议系统讲一下。

一、EAV 的核心思想

传统表结构：

产品( id, 名称, 颜色, 尺寸, 重量 )

问题：属性经常变，加字段成本高。

EAV 思路：

• Entity：数据主体（如商品、患者）
• Attribute：属性定义（如颜色、重量）
• Value：属性对应的值

把“列”变成“行”。

二、最基础的 EAV 表结构

1️⃣ 实体表（Entity）

entity (
  id BIGINT PRIMARY KEY,
  type VARCHAR(50)  -- 如 product / patient
)

2️⃣ 属性表（Attribute）

attribute (
  id BIGINT PRIMARY KEY,
  name VARCHAR(100),     -- 颜色
  data_type VARCHAR(20)  -- string / int / decimal / date
)

3️⃣ 值表（Value）

entity_attribute_value (
  entity_id BIGINT,
  attribute_id BIGINT,
  value_string VARCHAR(255),
  value_number DECIMAL,
  value_date DATE,
  PRIMARY KEY (entity_id, attribute_id)
)

✅ 一个实体可以有任意多个属性
❌ 值类型需要分列或用统一类型（如 TEXT）

三、常见 EAV 变体

✅ 变体 1：单一 value 列（最简单）

value TEXT

• 优点：简单
• 缺点：类型不安全，查询慢

✅ 变体 2：按类型分表（推荐）

eav_string_values
eav_int_values
eav_decimal_values
eav_date_values

• 查询效率高
• 结构稍复杂

✅ 变体 3：JSON 辅助（现代方案）

entity (
  id,
  attributes JSONB
)

配合 EAV 表做索引和查询。

四、查询示例

查“红色且重量 > 1kg 的商品”

SELECT e.id
FROM entity e
JOIN eav v1 ON e.id = v1.entity_id
JOIN attribute a1 ON v1.attribute_id = a1.id
JOIN eav v2 ON e.id = v2.entity_id
JOIN attribute a2 ON v2.attribute_id = a2.id
WHERE a1.name = '颜色' AND v1.value_string = '红'
  AND a2.name = '重量' AND v2.value_number > 1

⚠️ 多属性查询会产生大量 JOIN

五、EAV 的优缺点

✅ 优点

• 高度灵活
• 适合属性动态变化
• 无需改表结构

❌ 缺点

• 查询复杂
• 性能差（尤其多属性过滤）
• 数据校验弱
• 不适合高频事务

六、EAV 设计最佳实践

✅ 1. 不要“全表 EAV”

• 稳定字段 → 普通列
• 动态字段 → EAV

product (
  id,
  name,
  price,
  -- 动态参数用 EAV
)

✅ 2. 加元数据约束

• attribute 表加：
  • 是否必填
  • 单位
  • 枚举值

✅ 3. 加索引

INDEX (attribute_id, value_number)

✅ 4. 用视图或物化视图

product_view AS
SELECT ...

让业务层“看起来像宽表”

✅ 5. 考虑替代方案

• JSON / JSONB
• NoSQL（MongoDB）
• 宽表 + 动态列

七、适用场景总结

✅ 适合：

• 商品参数
• 医疗记录
• 自定义表单
• 配置系统

❌ 不适合：

• 核心交易数据
• 强一致性业务
• 高频聚合查询

如果你愿意，我可以：

• 给你一个完整电商 EAV 建表 SQL
• 或对比 EAV vs JSON vs 宽表
• 或针对你当前业务设计一套 EAV 方案

你现在是打算用在什么系统里？