动态表单存储设计

前言

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 + 关系型数据库的设计也能够是一个备选的方案。