动态表单数据存储选型：单表多列还是分表存储？

我之前做低代码表单编辑器时，刚好碰到过一模一样的问题——既要兼容多种字段类型的存储，又不能用非关系型数据库，还要避开原方案的那些坑。结合实际落地经验，给你推荐一个优化后的EAV（实体-属性-值）模型，完美适配你的需求：

核心表结构设计 #

只需要4个核心表就能搞定所有场景，数据完全集中存储：

1. 表单模板表 (form_templates) #

存储表单的基本信息，相当于每个表单的“元数据容器”：

CREATE TABLE form_templates (
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(100) NOT NULL, -- 表单名称
    description TEXT, -- 表单描述
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

2. 表单字段定义表 (form_fields) #

记录每个表单下的具体字段配置，明确每个字段的类型、规则和关联关系：

CREATE TABLE form_fields (
    id INT PRIMARY KEY AUTO_INCREMENT,
    template_id INT NOT NULL, -- 关联表单模板ID
    field_name VARCHAR(50) NOT NULL, -- 字段标识（比如username）
    display_name VARCHAR(100) NOT NULL, -- 前端显示名称
    field_type ENUM('varchar', 'text', 'float', 'select_single', 'select_multi', 'select_foreign') NOT NULL, -- 字段类型
    varchar_length INT DEFAULT 255, -- 仅varchar类型生效
    foreign_table_name VARCHAR(100), -- 仅select_foreign类型生效：关联的现有表名（比如users）
    options TEXT, -- 仅select_single/select_multi生效：下拉选项（JSON格式存储）
    FOREIGN KEY (template_id) REFERENCES form_templates(id)
);

3. 表单记录表 (form_records) #

存储每一次表单提交的主记录，相当于“实体”的标识：

CREATE TABLE form_records (
    id INT PRIMARY KEY AUTO_INCREMENT,
    template_id INT NOT NULL, -- 关联所属表单模板
    submitter_id INT, -- 提交用户ID（可选）
    submitted_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (template_id) REFERENCES form_templates(id)
);

4. 字段值存储表 (record_values) #

这是核心存储表，专门存放每个字段的具体值，按字段拆分存储，避免大量NULL：

CREATE TABLE record_values (
    id INT PRIMARY KEY AUTO_INCREMENT,
    record_id INT NOT NULL, -- 关联表单记录ID
    field_id INT NOT NULL, -- 关联表单字段ID
    value_varchar VARCHAR(255), -- 存varchar类型值
    value_text TEXT, -- 存text/多选select（逗号分隔或JSON）值
    value_float FLOAT, -- 存float/range类型值
    value_foreign INT, -- 存关联现有表的外键值
    FOREIGN KEY (record_id) REFERENCES form_records(id),
    FOREIGN KEY (field_id) REFERENCES form_fields(id),
    UNIQUE KEY unique_record_field (record_id, field_id) -- 避免同一记录同一字段重复存储
);

方案优势（完美解决原方案痛点） #

• 彻底解决大量NULL问题：每个字段值单独成一行，只有对应类型的列会被填充，不会出现方案一中一条记录带几十个空列的情况
• 完美支持SELECT的各种场景：
  • 多选存逗号分隔/JSON：直接放到value_text里
  • 关联现有表：把关联表的主键存到value_foreign，通过form_fields里的foreign_table_name就能关联到对应表查询
• 数据集中存储：所有表单数据都集中在这4个表里，不需要像方案二那样维护N个类型表，增删查改只需要操作这几个表
• 扩展性极强：新增字段类型（比如date、int），只需要在form_fields的field_type里加枚举，在record_values里加对应的列即可

实际使用注意事项 #

1. 查询优化：如果要获取一条完整的表单记录，需要通过record_id把record_values的多行数据聚合起来，后端可以用代码把多行转成一个JSON对象；如果需要批量查询，记得给record_id+field_id加联合索引，提升JOIN速度
2. 数据校验：在业务层要根据form_fields的字段类型，校验record_values里对应列的值是否合法（比如float类型不能往value_varchar里存），避免脏数据
3. 性能考量：如果表单字段数量特别多（比如每个表单有上百个字段），可以考虑把常用字段（比如提交时间、用户ID）放到form_records里，减少JOIN次数

对比原方案 #

内容的提问来源于stack exchange，提问作者Katai