利用在線編輯器設計的表單，包含輸入框，明細表（動態添加行）等需要存儲到數據庫的信息，現在有三種思路：
1.一個表單對應數據庫的一張或多張物理表（主從表），這種設計在很多業務的情況下，其數據庫的物理表會不斷膨脹，同時，當修改表單時，其對應的物理表結構也需要修改，當物理表很多數據時，改變物理表scheme會鎖表，導致在線應用訪問這些表。
2.利用橫向表縱向存儲的思路，即一張物理表保存的是所有表單對應的字段信息和對應的值，這樣的好處就是擴展表單（如添加一個字段）時只需要往這樣表插入一條數據，但隨着表單的增加，這張表的信息量將成倍數級增長，同時對后邊數據的呈現，數據的統計查詢造成很大影響。
3.利用現在的無scheme數據庫及nosql數據庫進行表單字段及值（key：value）的存儲，這樣修改表單很方便，但對於數據存儲每次都需要解析html有哪些字段（key）需要存儲到數據庫，還有其值是什么，同時，對於后面的數據統計，報表展現也難以實現，因為向mongodb這樣的數據庫，對數據統計的功能還是非常弱的。
有哪位大牛做過類似的動態表單設計器，可以說一下你的實現思路嗎？
討論一
第一種方式就當做沒發生過吧
第三種的話其實是不錯的方式，接觸過類似的國外站點，完全基於nosql的數據庫，方便擴展，很多高級的數據庫對報表支持也不弱
第二種方式可以稍微細致說一說，很多市面上的自定義報表軟件或者工具都是基於此設計的，曾經做過相關項目，對復雜表單的支持稍微弱一點，基礎表單還是沒有問題的，設計模仿數據庫的設計，定義表（CustomTableConfig），定義表字段（CustomTableFieldConfig），然后有一張實例表（TableInstance）和實例屬性表（tableFiledInstance），fieldInstance指向TableInstance和fiedConfig，fiedConfig和tableInstance指向tableConfig，field要有字段類型，字段名稱，字段長度，字段編號等屬性，可以擴展自動更新和ID自增長等屬性。表實例其實就相當於表的記錄了。可以針對這個設計對crud進行一定封裝，已達到與數據庫操作相一致的效果。如果要擴展關聯表，樓主可以進一步創建一個外鍵配置表和一個外鍵實例表，不過支持復雜表結構的話，上面提到的封裝會復雜許多
討論二
有一種方案，類似你的第二種方式吧，但是也有缺點。准備兩張表。一張用來做橫表，表A，擴展表單時（如添加一個字段），就往這表里插入一條數據。
另一張表。表B，用來正常存儲數據，字段名不再是和業務有關的，全部用類似key1,key2,key3……等等，和表A中表單field name一一對應，表2的列可以預先准備n列，如果表2的列不夠用了，再在程序中動態添加m列。
先說優點吧，相比你第一個方案，大大減少了修改表結構的次數，甚至預先准備的列夠用的話，不需要修改表結構了。然后由於存儲數據的表2依然是常見的關系型結構，所以對於數據統計查詢的核心sql不會造成影響。
特別提到核心sql不受影響，因為這個方案缺點也很明顯。每次查詢都要做一個從表A到表B的關聯。先從表A從獲取你想select的表名，以及哪些key1, key2, key5, key6 。。。 然后根據這些從表2中拿數據。還是有點小麻煩的。