EAV（Entity-Attribute-Value，实体-属性-值）模型是一种灵活的数据存储方式，常用于传统关系型数据库无法很好应对“结构高度动态、属性稀疏”的场景。下面从为什么用、适合什么、有什么代价三个角度说明。
传统表结构要求先定义列：
user(name, age, email)
但如果不同用户有不同属性（身高、血型、爱好、医保号……），列会爆炸式增长。
EAV 把结构变成：
(entity, attribute, value)
✅ 新增属性 不需要改表结构
很多实体只有少数属性：
用宽表会大量 NULL； 用 EAV 只存“有值的属性”，节省空间、避免空列。
典型场景：
业务方可以：
“加个字段” → 直接插数据，不改数据库
EAV 常配合：
可支持：
✅ 适合：
❌ 不适合：
-- 查“年龄=18 且 性别=男”
SELECT *
FROM eav
WHERE (attribute='age' AND value=18)
AND (attribute='gender' AND value='male')
需要 pivot / join，SQL 很难写。
| 方案 | 说明 |
|---|---|
| JSON / JSONB 字段 | 关系型数据库内灵活存储 |
| 文档数据库（MongoDB） | 天然适合动态结构 |
| 宽表 + 扩展字段 | 核心固定 + 扩展灵活 |
| 混合模型 | 核心用表，扩展用 EAV/JSON |
EAV 是为了“灵活”牺牲“简单和性能”的模型，只在属性高度不确定时才值得用。
如果你有具体业务场景（电商 / 医疗 / 配置系统），我可以帮你判断该不该用 EAV。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
