做架构师这些年，被问最多的一个问题就是：表单引擎的数据到底该怎么存。业务部门自己搭应用，表单五花八门，今天一张报修单八个字段，明天一张点检表二十个字段，后台存储是按每张表单建结构化宽表，还是统一塞进文档型存储，这个选择影响深远。这篇把两种方案的取舍逻辑讲透。结论先行：中小规模的表单引擎，文档型存储起步，配套字段元数据层；等查询和统计需求长出来，再按热点表单局部升级宽表，全宽表起步几乎必然后悔。
一、两种存储范式的真面目
1.1 宽表派的做法
宽表派的做法传统而硬核：每张表单对应一张物理表，表单里的每个字段对应一列，字段类型就是列类型。优点直白：类型约束天然存在，SQL 查询过滤统计全链路顺畅，优化器知道每一列的类型和分布，索引该建就建。缺点同样直白：表单结构一变就要改表结构，业务人员改表单的自由被数据库锁死；几百张表单就是几百张物理表，数据字典的膨胀速度超出想象。
1.2 文档库派的做法
文档库派把每条表单提交存成一个文档：字段名做键，字段值做值，整单入库。表单结构怎么变，存储层纹丝不动，业务人员的搭建自由得到彻底释放。代价在查询侧：按某个字段过滤要扫描文档内容，统计聚合要走应用层或专门的索引设计；跨表单的关联分析更是文档库的弱项。自由和秩序，在存储选型上就是一对天生的矛盾。
1.3 真正的问题是规模与用法
两派吵不出结果，因为都默认自己的前提。宽表派的前提是表单少而稳定、查询重；文档库派的前提是表单多而多变、写入重。真实的业务里两种前提都成立------热点的核心表单(报修、点检、审批)查询重，长尾的临时表单(活动登记、临时盘点)写入轻查询几乎为零。所以正确的问题不是选哪派，是怎么把两种范式按需组合。
二、文档型起步的完整设计
2.1 主表与文档表的分工
起步方案用两张表撑起全部表单。主表记表单元数据：表单标识、名称、版本、状态；文档表记提交数据，一行一次提交：
sql
CREATE TABLE form_submission (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
form_id INT NOT NULL,
version INT NOT NULL,
data JSON NOT NULL, -- 全部字段值
created_by VARCHAR(16) NOT NULL,
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
KEY idx_form_time (form_id, created_at)
);data 列存整单字段。查询入口永远从 form_id 加时间进入，索引保证按表单拉数据不慢。这个结构对表单数量完全免疫：一张表单和一千张表单，存储层是同一套，运维心智不变。
2.2 字段元数据层不能省
光有文档表不够，字段元数据层是文档方案的地基：每张表单的每个字段，名称、类型、必填、枚举值、校验规则，全部登记在元数据表里。写入时按元数据校验，读取时按元数据渲染，导出时按元数据生成表头。没有这一层，文档数据就是一堆无法解读的裸值------半年后连当初建表单的人都说不清某个键是什么意思。元数据层就是文档方案的数据字典，它的质量决定整套方案能活多久；字典散了，文档数据就成了谁也读不懂的天书。
2.3 生成列做查询索引
文档方案最常见的质疑是字段查询慢，解法是生成列：把高频查询字段从文档里提出来，建成虚拟生成列并加索引：
sql
ALTER TABLE form_submission
ADD COLUMN dept VARCHAR(32)
GENERATED ALWAYS AS (JSON_UNQUOTE(data->'$.dept')) STORED,
ADD COLUMN urgency TINYINT
GENERATED ALWAYS AS (data->'$.urgency') STORED,
ADD KEY idx_dept_urgency (dept, urgency);哪些字段提为生成列，看真实查询日志：被过滤排序最狠的前几个字段值得提，其余留在文档里。这是文档方案的精妙之处------查询性能按需购买，热点字段付索引的代价，冷字段零成本躺着，钱花在刀刃上。
2.4 版本变更的兼容
表单改版后旧数据怎么办，元数据层给出答案：提交记录带版本号，读取时按提交时的表单版本渲染。旧版本表单的元数据永不删除，历史提交永远能按当时的模样回放。这个设计在审计场景救过命：有人质疑半年前的一张审批单字段不全，调出当时的表单版本，证明那个版本根本没有这个字段，一场争议就此化解。
三、局部升级宽表的时机
3.1 三个升级信号
文档方案跑得再好，有些表单终会长成核心资产。升级信号有三个：统计报表依赖这张表单，聚合查询频繁且慢；跨表单关联分析常态化，比如报修单要关联设备档案和备件出库；数据量突破百万级，生成列索引开始不够用。三个信号出现任意两个，就该考虑把这张表单的数据物化成宽表。
3.2 物化视图式的升级
升级不是推倒重来，而是加一层物化：定时任务把文档数据抽取进宽表，宽表按查询需求建模，该分区分索引随心所欲。文档表继续作为事实源，写入路径不变，业务无感；宽表是查询加速层，报表全走宽表。这个双层结构兼顾了两派的优点------写入侧的自由和查询侧的秩序，代价是数据从文档到宽表有分钟级延迟。报表场景对这点延迟几乎从不敏感。
3.3 别做的事
两条红线守住。不要跳过文档层直接把宽表当事实源，表单改版时你会陷进改表结构、迁历史数据的泥潭；不要为长尾表单预建宽表，九成以上的临时表单一辈子用不上一次复杂查询，为它们建宽表是纯浪费。存储方案的铁律：为已发生的需求买单，不为想象中的需求预付。
四、一个真实规模的验证
这套分层方案在我们服务的一家企业跑了两年：表单数量六百多张，提交总量四百多万条，其中被物化成宽表的核心表单十一张，覆盖了全部报表和关联分析需求。文档主表加生成列索引，日常查询九成五在两百毫秒内；宽表层支撑月度经营分析，原来跑不动的跨表单关联，现在一条join完事。回头看，如果起步就上六百张宽表，数据库早被表结构变更淹死；如果坚持纯文档不物化，报表部门也早造反了。组合拳才是活路。
五、总结
表单引擎存储建模的决策树：起步用文档型加元数据层，自由和扩展性全拿到手；查询热点用生成列按需加索引，性能问题点状解决；核心表单长成后物化宽表做查询层，报表和关联分析的秩序需求局部满足。全宽表和纯文档都是极端，真实世界的正确答案几乎总是中间态。架构师的价值不在于站队某个范式，而在于设计出让范式可以随业务演进而切换的结构。
常见问题
问:文档字段里的数字和日期,排序和比较会不会出问题?
答:会,这是文档方案的头号坑。值以字符串形态存进文档时,按字符串比较,日期和数字的排序都会错乱。解法在元数据层:字段类型登记清楚,写入时数字存数字、日期统一格式;生成列提字段时显式转换类型;应用层读取时按元数据类型解析。类型纪律从写入那一刻就要守住,事后清洗的代价十倍不止。
问:生成列加多了会不会反而拖累写入?
答:会。每个存储型生成列意味着写入时多一次计算和索引维护,生成列十个以上、写入又频繁的表单,插入耗时会明显上涨。把握两个度:单张表单的生成列控制在五个以内;只给查询日志里真实出现的字段建,不凭感觉预建。生成列是性能的消费,不是免费的午餐,按需开通才是正解。
问:元数据层自己怎么管,会不会越管越乱?
答:元数据只随表单设计器变更:业务人员在设计器里改字段,元数据自动同步,禁止任何手工直改数据库。每次变更留版本快照,谁在什么时候改了什么,全程可查。再配每季度的元数据体检:孤儿字段(元数据有但文档从未出现)清理,高频裸键(文档有但元数据缺失)补登。元数据层的秩序,靠的是入口唯一加定期体检。
问:什么规模才值得直接上专业文档数据库?
答:看三个指标的组合:提交量日均百万级以上、文档平均字段数过百、跨表单实时查询需求多。三者同时成立,关系型数据库里的文档方案开始吃力,值得评估专业文档库。只满足一两条,先在现有方案里优化,换数据库的迁移成本远超多数人的预估,没有压垮性的证据,不要轻动地基。