在SaaS系统、平台型应用或高度可配置的企业级软件中，我们常常会遇到一个现实问题：不同客户对同一个业务表存在差异化字段需求。例如，A客户需要一个“业务员等级”字段，B客户不需要；C客户希望订单表中增加“海外仓编码”，D客户则希望订单表有“渠道来源URL”。这些差异不断出现、演变，带来了数据库设计上的挑战。

本文将深入探讨：在一个成熟产品中，如何设计数据库架构以应对客户字段多样化，确保系统的可维护性、可扩展性和高性能。

一、问题背景与挑战

1.1 背景

一个标准化产品如果走向ToB市场，就不可避免地面临客户定制化的需求。尤其是中大型客户，往往会对数据结构提出独特诉求。

1.2 典型挑战

字段扩展频繁：随着客户增长，每个月可能新增若干定制字段。
字段逻辑耦合：某些字段会影响业务逻辑（如流程、权限、报表）。
前端适配困难：页面组件渲染、校验、表单展示需动态调整。
报表复杂化：字段不一致时，跨客户的统计变得困难。
数据库膨胀：字段数量庞大，导致表设计臃肿，查询性能下降。

二、常见的数据库设计策略对比

方案	描述	优点	缺点
1. 表字段扩展（传统）	在主表直接增加新字段	简单直观	可维护性差、字段爆炸、跨客户不统一
2. 子表设计（垂直扩展）	主表 + 客户扩展字段子表	避免主表污染	JOIN性能差、字段类型不统一
3. JSON字段存储	使用如 `extra_data JSON` 存储动态字段	支持灵活扩展	查询不便、索引不支持、校验弱
4. EAV模型（实体-属性-值）	把字段设计为属性表（Entity-Attribute-Value）	极致灵活	性能极差、开发复杂度高
5. 多租户表结构 + Schema分离	每客户独立表结构或数据库Schema	最大定制自由度	成本高、发布复杂、跨客户统计困难

三、推荐策略：主表 + JSON扩展字段 + 动态字段注册机制

针对实际中多数SaaS系统，我们推荐采用混合策略：

3.1 主表保留标准字段

主表只存放所有客户通用字段，如 id, order_no, status, created_at 等。
这些字段能支持平台标准功能、系统报表、通用API。

3.2 动态字段采用 JSON 扩展

设置一个如 ext 的字段，类型为 JSONB（PostgreSQL）或 JSON（MySQL）。
每个客户的定制字段放入该字段中，支持任意键值对结构。

3.3 字段注册中心设计

为了避免“无序增长”，建立字段注册系统，用于描述每个客户的扩展字段元数据：

create table customer_field_def (id bigint primary key,customer_id bigint,table_name varchar(64),field_key varchar(64),field_label varchar(128),field_type varchar(32),required boolean,searchable boolean,created_at timestamp
);

配合该结构，系统可以：