宽表设计（Wide Table） 与 子表 + 类型 + 属性表设计（EAV 模型或“属性表”模型）
在软件系统设计中，属性扩展（尤其是面向动态业务字段的扩展）是一个常见问题。尤其在企业应用、CMS、电商平台等场景中，经常会遇到「某个对象可能会增加不同的字段」的需求，例如：商品新增自定义字段、用户增加扩展信息等。
本文将讨论两种主流方案 —— 宽表设计（Wide Table） 与 子表 + 类型 + 属性表设计（EAV 模型或“属性表”模型），并从可维护性、性能、适用场景等方面进行系统分析。
一、方案一：宽表设计（Wide Table）
设计思路：
在主表中预定义大量的扩展字段，比如：
CREATE TABLE product (id BIGINT PRIMARY KEY,name VARCHAR(100),category_id INT,ext1 VARCHAR(255),ext2 VARCHAR(255),...ext50 VARCHAR(255)
)
或采用动态建字段的方式，在数据库中给每个客户、场景、字段需求增加真实字段（如 color, size, brand, origin 等）。
优点：
-
高性能查询：字段结构清晰，查询语句简单高效，易于建索引、统计分析。
-
开发简洁：ORM 映射直接支持字段，无需额外联表、反序列化。
-
适合字段固定场景：若扩展字段是少量且不经常变动，可快速上线。
缺点：
-
可维护性差：字段扩展需要改表结构，DDL操作不利于系统运行。
-
字段稀疏：大部分字段为空，造成数据库空间浪费。
-
难以通用建模：无法支持多类型对象或业务场景的动态属性。
二、方案二：子表 + 类型 + 属性表（EAV 模型）
设计思路：
采用实体-属性-值模型（Entity-Attribute-Value, 简称 EAV），将扩展字段存入子表中：
CREATE TABLE product (id BIGINT PRIMARY KEY,name VARCHAR(100),category_id INT
);CREATE TABLE product_attribute (id BIGINT PRIMARY KEY,product_id BIGINT,attr_code VARCHAR(100),attr_value TEXT
);
还可增加字段定义表以支持类型、校验、输入控件：
CREATE TABLE attribute_definition (attr_code VARCHAR(100) PRIMARY KEY,name VARCHAR(100),input_type VARCHAR(50), -- 如 text, select, checkboxdata_type VARCHAR(50), -- 如 string, number, dateis_required BOOLEAN
);
优点：
-
高度灵活：字段可以随时扩展，无需改表结构。
-
支持多类型对象共用设计：多个实体共用一套属性表机制。
-
适合多租户 / SaaS 场景：每个租户可自定义属性而不影响其他租户。
-
可支持属性配置：如是否必填、字段顺序、字段说明等。
缺点：
-
查询性能差：需要联表、转置数据，尤其在大数据量下代价高。
-
开发复杂度高：需要动态处理属性值、类型转换、字段展示。
-
不易进行聚合分析：如 SUM、AVG、GROUP BY 等聚合场景需额外转化。
三、对比分析
| 维度 | 宽表设计 | 子表属性设计（EAV） |
|---|---|---|
| 可扩展性 | 差，需要频繁改表 | 强，支持动态扩展字段 |
| 查询性能 | 强，字段直查 | 弱，需联表或转置 |
| 结构复杂度 | 低，单表操作 | 高，涉及多个表、逻辑复杂 |
| 适合场景 | 字段少变更、查询频繁 | 多类型、多字段、结构不固定 |
| 维护成本 | 表结构难维护，升级风险高 | 结构稳定，逻辑维护成本较高 |
| 多语言支持 | 不便于字段国际化 | 易于属性表中设置字段名称和多语言描述 |
四、实际应用建议
建议一：按场景权衡选择
-
若字段较固定、查询密集、分析性强（如报表系统） → 优先宽表设计
-
若字段经常变化、种类繁多、多租户定制性强 → 采用子表属性设计
建议二：混合模型设计
在实际项目中，常采用混合建模，即：
-
核心字段放在主表（宽表）中；
-
非核心字段采用属性表方式管理。
例如：
商品主表字段：
- id, name, price, stock → 宽表字段商品扩展字段：
- 材质、适用人群、自定义标签 → 子表属性表
这样既保障了性能，又兼顾了扩展性。
五、总结
属性扩展方案的选型需要结合业务的变动频率、字段数量、查询性能要求进行系统权衡。
-
宽表设计适用于结构固定、高性能场景
-
子表+属性模型适用于字段动态、场景复杂场合
-
混合建模是实用主义最优选择
从架构角度，应抽象出统一的属性引擎（Attribute Engine）层，将业务层从底层属性结构中解耦，提供统一的动态字段注册、存取、校验、展示能力。