動態表單存儲設計

前言

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 + 關係型數據庫的設計也能夠是一個備選的方案。