2023年7月25日发(作者：)

动态表单存储设计前⾔Flowable, Activiti 等开源解决⽅案所提供的表单引擎是没有业务表单数据持久化的功能（即⾃动创建表，将表单数据持久化功能），只提供动态表单创建以及渲染功能。⽬前来看表单引擎服务主要功能如下：动态表单配置以及渲染（主要在于前端实现）表单数据库持久化以下是⽬前实现业务表单数据持久化的⼏种⽅案：以下⽅案都以请假流程的表单为例，⽐较简单就请假天数（days）以及请假理由（reason）,动态表单如下所⽰：⽅案⼀：动态添加字段⼀个表单对应数据库的⼀张或多张物理表（主从表）针对请假流程如何操作呢？给请假流程表单创建⼀张数据表，包含字段 days 以及 reason 。其他业务表单也是如此操作。create table leave_data( days int default 0 null comment '请假天数', reason varchar(250) null comment '请假理由')comment '请假流程业务数据';该⽅案存在的问题:⼀个表单对应数据库的⼀张或多张物理表，随着业务的增多，数据库的物理表会不断膨胀。业务表单字段需要修改时（⽐如给请假流程添加⼀个开始时间字段，就需要调整物理表结构），其对应的物理表结构也需要修改，在物理表很多数据时，改变物理表scheme会锁表。⽅案⼆：预留空⽩字段，动态分配业务数据存储表：create table data( name varchar(250) null comment '业务表单名', field_0 varchar(250) null comment '字段0', field_1 varchar(250) null comment '字段1', field_2 varchar(250) null comment '字段2', field_3 varchar(250) null comment '字段3')comment '业务数据';业务表单属性表：create table table_config( name varchar(250) null comment '表单名', field_name varchar(250) null comment '字段名', field_map varchar(250) null comment '字段映射')comment '表配置';实际操作下来，存储是这样哒：那么动态字段变更需要修改表字段配置表即可。缺点：操作数据的时候都需要先去 map 中转以下才能查询（程序层⾯可以解决）如果⼀张业务表保存所有的数据话，不利于优化（可以进⾏扩展，配置多张业务表，不过这样也可能会出现⽅案⼀中物理表爆炸的问题）⽅案三：属性使⽤ KEY/VALUE 格式存储将表单数据全部都⽤ Key/Value 的格式来存储。参考如下：create table attributes( f_id varchar(250) null comment '关联id', key varchar(250) null comment '属性', value varchar(250) null comment '属性值', field_2 varchar(250) null comment '字段2', field_3 varchar(250) null comment '字段3')comment '属性';具体操作后即是：动态添加属性字段只需要添加 Key/value。题外话，reddit 的数据库就两张表，也是这样的设计⽅案，不过现在已经改掉了，成为历史。缺点：不太好⽀持关联⼦表程序中处理取值不⽅便⽅案四：MongoDB ⽅案设计MongoDB ⽅案的话，只需要将前端发过来的JSON写⼊即可，这⾥还是以请假流程为例：集合内数据允许动态添加字段：集合类似于关系型数据库中的表，可以存储不规则的数据，只能说 Mongodb 擅长⼲这种事情。总结以上⽅案设计⽣产环境使⽤还需要改进使⽤，⽬前市⾯上⽤的多得应该是⽅案⼆，MongoDB 也是⼀个不错选项，仅在数据持久化这块，具体业务场景下使⽤ MongoDB + 关系型数据库的设计也可以是⼀个备选的⽅案。