EAV模型如何避免稀疏

EAV（Entity-Attribute-Value，实体-属性-值）模型本质上是用行代替列来存异构属性，因此“宽表稀疏”（大量 NULL 列）的问题在 EAV 中天然被规避了；但 EAV 自己也会带来另一种稀疏/低效问题：

• 行数爆炸（一个实体成百上千行）
• 查询时要大量 JOIN / 行转列
• 空值以“不存在行”形式出现，统计和索引难做

所以“避免稀疏”通常指两件事：避免存储稀疏 和 避免查询/使用时的逻辑稀疏。下面分层说。

一、为什么 EAV 本身不“稀疏”

传统宽表：

user(id, name, height, blood_type, favorite_brand ...)

多数用户只填部分字段 → 大量 NULL。

EAV：

entity_attr(entity_id, attr_id, value)

只存“有值的属性”，没有值就不插入行。
✅ 存储上不稀疏。

二、EAV 常见的“伪稀疏”问题及规避方式

1. 行转列导致的使用稀疏

查询一个实体全部属性时：

SELECT attr_id, value
FROM eav
WHERE entity_id = 1;

结果是“竖表”，业务代码还要拼。

规避：

• 对高频属性做 物化视图 / 宽表同步
• 用 JSON 聚合（MySQL 5.7+ / PG）

SELECT entity_id,
       JSON_OBJECTAGG(attr_id, value)
FROM eav
GROUP BY entity_id;

2. 类型稀疏（所有值都是字符串）

EAV 常把 value 存成 VARCHAR，导致：

• 数字/日期丢失类型
• 索引失效

规避：

• 多值列设计：

value_string, value_int, value_datetime, value_decimal

• 或按属性类型分表（EAV + 类型表）

3. 高频属性造成的“假 EAV”

如果 80% 实体都有 name / status / created_at
→ 放 EAV 是过度设计。

规避（混模）：

• 固定属性 → 主表列
• 真正异构属性 → EAV

这是生产中最常见做法。

4. 查询稀疏（JOIN 爆炸）

WHERE attr='age' AND value>30
  AND attr='city' AND value='BJ'

容易写成多次 JOIN。

规避：

• 预聚合标签表
• 使用列式存储 / ES
• 用 GROUP BY + HAVING 代替多 JOIN

三、现代“无稀疏”替代方案（比 EAV 更好）

✅ JSON / 半结构化列

user(id, attrs JSONB)

• 不稀疏
• 可索引（PG GIN）
• 查询友好

✅ 宽表 + JSON 混合

• 主表：稳定字段
• JSON：扩展字段

✅ 图 / 文档数据库

• Neo4j（属性图）
• MongoDB（schema-less）

四、经验结论

EAV 不是用来“避免稀疏”的银弹，而是用来“支持无限属性”的妥协方案。

最佳实践：

1. 固定属性 → 列
2. 少量异构属性 → JSON
3. 真·海量动态属性 → EAV + 聚合层

如果你愿意，可以告诉我：

• 用的数据库（MySQL / PG / ES）
• 属性规模（几十 / 几万）
• 读多还是写多

我可以直接给你表结构设计示例。