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中拿資料。還是有點小麻煩的。
資料庫結構設計
1.3概念設計的任務 1.2概念設計的依據 需求分析的文件，需求說明書，功能模型 資料流圖或idef0圖 資訊模型 er圖 和資料庫概念說明書是資料庫邏輯設計的依據 1.2 資料庫概念設計過程 1.3 資料建模方法 er建模方法 idef1x建模方法標識er模型中的聯絡，依次轉換與每個聯絡相關聯的實...
資料庫表結構設計 動態字段
專案中遇到要動態對錶的字段進行操作 增加或者刪除，很頭疼，網上查了資料，整理一下。具體還沒去實現，後續還需研究 看到一篇文章，參與團員管理系統資料庫設計時，使用者提出了無限擴充套件團員屬性和隨時修改屬性名的要求 兩大難題 不定字段數目的資料庫表設計和資料結構 1 不定字段數目的資料庫表的設計 需要一...
redis資料庫結構設計
之前遊戲開發服務端都是用純c 來寫，現在很多寫遊戲伺服器越來越傾向指令碼語言，因為用c 來寫一些邏輯的確是痛苦之極，當然如果追求效率的還是用c c 實現更好。最近時間自己通過研究了解雲風寫的skynet框架學習了lua，研究skynet其實是想把這框架用到公司現在遊戲專案裡替換掉現在用的乙個純c 框...