EAV模型与普通表有何不同

EAV（Entity–Attribute–Value，实体–属性–值）模型与传统的“普通表”（即宽表/固定列模型）是两种不同的数据库建模方式。下面从结构、优缺点、适用场景等方面对比它们的不同。

一、结构上的不同

1. 普通表（固定列模型）

• 每一类实体对应一张表
• 每个属性是表中的一个列
• 一行代表一个实体实例

示例（用户表）：

users
| id | name  | age | city   |
|----|-------|-----|--------|
| 1  | Alice | 30  | Beijing|
| 2  | Bob   | 25  | Shanghai|

特点：

• 结构稳定
• 字段清晰
• 查询直观

2. EAV 模型

• 实体、属性、值分开存储
• 通常用三张核心表（或一张通用表）

示例：

entities
| entity_id | entity_type |
|-----------|-------------|
| 1         | user        |

attributes
| attr_id | attr_name |
|---------|-----------|
| 1       | name      |
| 2       | age       |
| 3       | city      |

values
| entity_id | attr_id | value     |
|-----------|---------|-----------|
| 1         | 1       | Alice     |
| 1         | 2       | 30        |
| 1         | 3       | Beijing   |

特点：

• 属性可动态增加
• 不需要改表结构
• 一行只存一个“属性值”

二、核心区别对比

三、优缺点总结

普通表

优点

• 查询简单、性能好
• 易于索引、约束、校验
• 对开发友好

缺点

• 属性变更需 DDL
• 稀疏字段浪费空间
• 不适合高度异构数据

EAV 模型

优点

• 支持动态属性
• 适合元数据驱动系统
• 避免频繁改表

缺点

• 查询需大量 JOIN 或 PIVOT
• 类型安全差
• 容易产生数据质量问题
• 性能和维护成本高

四、典型使用场景

适合普通表

• 用户、订单、商品等结构稳定系统
• 高并发、强事务业务

适合 EAV

• 医疗记录（不同病种字段差异大）
• 商品属性（电商 SKU 属性不固定）
• 配置系统、元数据结构
• CMS、低代码平台

五、折中方案（常见实践）

实际项目中常采用混合模式：

• 核心字段用普通表
• 扩展属性用 EAV / JSON

例如：

users (普通表)
+ profiles_json (JSON 扩展字段)

或：

• 普通表 + EAV 表
• 普通表 + NoSQL（MongoDB）

如果你愿意，我也可以：

• 用具体业务例子对比
• 讲 EAV 的 SQL 查询写法
• 分析 EAV 的性能优化方案