如何用EAV模型

EAV（Entity–Attribute–Value，实体-属性-值）模型是一种用来处理高度动态、属性稀疏且结构不固定数据的数据库建模方式。下面我从概念 → 适用场景 → 表结构设计 → 示例 → 优缺点 → 实践建议一步步说明。

一、EAV 是什么？

传统表结构：

用户表：id, name, age, email

如果不同用户有不同的属性（身高、爱好、医保号、设备型号……），表会无限膨胀。

EAV 把数据拆成三列：

• Entity（实体）：谁
• Attribute（属性）：什么字段
• Value（值）：字段的值

二、什么时候用 EAV？

✅ 适合：

• 属性数量不固定（CMS、商品属性、医疗记录）
• 不同实体属性差异大
• 需要动态扩展字段

❌ 不适合：

• 属性固定且查询频繁
• 对性能、统计要求极高

三、EAV 基本表结构

1️⃣ 实体表

entities (
  id INT PRIMARY KEY,
  type VARCHAR(50)  -- user / product / patient
)

2️⃣ 属性表

attributes (
  id INT PRIMARY KEY,
  name VARCHAR(50),
  data_type VARCHAR(20) -- string / int / date
)

3️⃣ 值表（核心）

entity_values (
  entity_id INT,
  attribute_id INT,
  value TEXT,
  PRIMARY KEY (entity_id, attribute_id)
)

四、示例：用户属性

属性：

• 年龄
• 爱好
• 医保号

数据：

entity_values
entity_id | attribute_id | value
1         | 1            | 28
1         | 2            | 篮球
2         | 3            | M123456

查询用户 1 的所有属性：

SELECT a.name, v.value
FROM entity_values v
JOIN attributes a ON v.attribute_id = a.id
WHERE v.entity_id = 1;

五、EAV 的优缺点

✅ 优点

• 极度灵活
• 无需改表结构
• 适合配置化系统

❌ 缺点

• 查询复杂（大量 JOIN）
• 类型不安全
• 索引和统计困难

六、常见优化方案

1. 按类型分表（用户EAV / 商品EAV）
2. JSON 字段（MySQL / PostgreSQL）

users (
  id INT,
  attrs JSON
)

3. EAV + 宽表混合

• 常用字段：普通列
• 不常用字段：EAV

七、简单总结

EAV 不是“更好”的模型，而是**“更灵活但更复杂”的模型**。
能不用就不用，不得不用时再上。

如果你有具体场景（电商 / 医疗 / 配置系统），我可以帮你设计一套 EAV 表结构。