为什么要用EAV模型建站

EAV（Entity-Attribute-Value，实体-属性-值）模型是一种用来存储高度动态、稀疏数据的数据库设计方式。在“建站”（尤其是电商、CMS、PIM、CRM 类系统）场景中被广泛使用，核心原因可以归纳为以下几点：

一、为什么要用 EAV 模型建站

1. 应对“属性高度不确定”的业务

很多网站（尤其是电商、商品库、自定义表单）面临一个问题：

• 不同商品类型属性差异极大（手机有“屏幕尺寸”，衣服有“尺码”）
• 后期还会不断增加新属性

如果用传统表结构：

products (
  id, name, price, size, color, screen, weight, ...
)

会导致：

• 表字段爆炸
• 大量空值（稀疏数据）
• 改表成本高（DDL 风险）

EAV 把结构变成数据：

Entity: 商品ID=1
Attribute: 颜色
Value: 红色

2. 支持用户自定义字段

很多建站系统（如 Magento、WordPress 高级字段、 Drupal）允许：

• 运营自己加字段
• 不同站点不同结构

EAV 可以不改数据库结构就支持新属性。

3. 适合“稀疏数据”

如果一个实体有 500 个可能属性，但每个实体只用 10 个：

• 普通表：500 列 × 大量 NULL
• EAV：只存用到的 10 行

存储更高效（逻辑上）。

4. 多租户 / 多站点灵活建模

SaaS 建站平台常面对：

• A 客户要“会员等级”
• B 客户要“积分规则”

EAV 可做到：

• 一套表
• 多套属性配置

二、典型使用场景

• 电商商品属性（Magento）
• 内容管理（Drupal）
• 产品信息管理系统（PIM）
• 低代码 / 无代码建站平台
• 动态表单系统

三、EAV 的代价（必须知道）

EAV 不是“银弹”，问题也很明显：

1. 查询复杂

SELECT ...
FROM entity e
JOIN eav a1 ON a1.entity_id = e.id AND a1.attr='color'
JOIN eav a2 ON a2.entity_id = e.id AND a2.attr='price'

2. 性能问题

• JOIN 多
• 索引难用
• 大表慢

3. 数据校验弱

• 类型、约束常在代码层
• 容易脏数据

四、什么时候“不该用 EAV”

• 属性固定且少
• 高性能查询需求
• 简单业务系统

更优方案可能是：

• 宽表
• JSON 字段（MySQL / PostgreSQL）
• 混合模型（核心字段 + JSON / EAV）

五、一句话总结

用 EAV 建站，本质是用“灵活性”换“复杂度”，适合属性多变、用户可定义的网站系统。

如果你愿意，我可以：

• 给你一个 EAV 建表示例
• 对比 EAV vs JSON 方案
• 结合你具体建站类型（电商 / CMS / SaaS）给建议