1.一個表單對應資料庫的一張或多張物理表（主從表），這種設計在很多業務的情況下，其資料庫的物理表會不斷膨脹，同時，當修改表單時，其對應的物理表結構也需要修改，當物理表有很多資料時，改變物理表scheme會鎖表，導致線上應用無法訪問這些表。（類似於我們公司的編目管理）

2.利用橫向表縱向儲存的思路，即一張物理表儲存的是所有表單對應的欄位資訊和對應的值，這樣的好處就是擴充套件表單（如新增一個欄位）時只需要往這樣表插入一條資料，但隨著表單的增加，這張表的資訊量將成倍數級增長，同時對後邊資料的呈現，資料的統計查詢造成很大影響。

3.利用現在的無scheme資料庫及nosql資料庫進行表單欄位及值（key：value）的儲存，這樣修改表單很方便，但對於資料儲存每次都需要解析html有哪些欄位（key）需要儲存到資料庫，還有其值是什麼，同時，對於後面的資料統計，報表展現也難以實現，因為像mongodb這樣的資料庫，對資料統計的功能還是非常弱的。