EAV核心概念
通过实体(Entity)、属性(Attribute)、值(Value)三表结构存储动态属性,解决传统表结构灵活性不足的问题。
适用场景:属性频繁变化、稀疏属性存储(如医疗指标、商品自定义字段)。
EAV表结构设计
标准三表结构
CREATE TABLE entity (
entity_id INT PRIMARY KEY,
name VARCHAR(100)
);
CREATE TABLE attribute (
attribute_id INT PRIMARY KEY,
attribute_name VARCHAR(50)
);
CREATE TABLE value (
entity_id INT,
attribute_id INT,
value VARCHAR(255),
PRIMARY KEY (entity_id, attribute_id)
);
数据示例
实体表
entity_id |
name |
1 |
商品A |
2 |
商品B |
属性表
attribute_id |
attribute_name |
101 |
color |
102 |
weight |
值表
entity_id |
attribute_id |
value |
1 |
101 |
红色 |
1 |
102 |
5kg |
2 |
101 |
蓝色 |
EAV查询示例
查询实体属性(如商品A的属性和值)
SELECT
a.attribute_name,
v.value
FROM value v
JOIN attribute a ON v.attribute_id = a.attribute_id
WHERE v.entity_id = 1;
查询结果
attribute_name |
value |
color |
红色 |
weight |
5kg |
EAV优缺点对比
优点 |
缺点 |
✅ 灵活支持动态属性 |
❌ 复杂查询需多次 JOIN |
✅ 避免频繁修改表结构 |
❌ 性能低(大数据量时明显) |
✅ 节省稀疏数据存储空间 |
❌ 数据校验困难(如类型、约束) |
EAV适用场景
- 1. 动态属性管理
- • 医疗系统(不同患者的检测指标不同)
- • 电商商品(不同类目属性差异大)
- 2. 自定义字段
EAV替代方案
需求 |
推荐方案 |
动态属性 + 结构化查询 |
JSON 字段(PostgreSQL/MySQL) |
高并发读写 + 灵活模式 |
NoSQL(MongoDB) |
固定属性 + 强一致性 |
传统关系表 |
EAV最佳实践
- 1. 混合存储
- 2. 分类型存储
CREATE TABLE value (
entity_id INT,
attribute_id INT,
string_value VARCHAR(255),
number_value DECIMAL,
date_value DATE
);
- 3. 添加元数据
- • 在
attribute
表中增加 data_type
字段约束类型
- 4. 缓存优化