我使用動態調查創建&提交組件創建了一個Web應用程序。我使用MongoDB來存儲表單和表單提交的模式。使用mongodb進行表單構建Web應用程序，模式注意事項
我可以想像幾種不同的方式組織本：
擁有所有表單提交和形式架構在單個集合文件。
對所有形式的模式和所有的表單提交
單獨集合有一個單獨的集合所有形式的模式，併爲每個模式的所有表單提交創建一個新的集合。
我還在研究這個，我來自RDBMS的世界，我是NoSQL數據庫的noob。任何人有任何建議？
EDIT 1 忘記處理嵌入的響應作爲表單模式文檔中的一處。
我會去兩個系列：表格和意見書。
這是一種水平放大的方法，因爲您只有2個集合需要擔心。
我同意@Gates VP關於提供自定義_id而不是默認objectId，因爲您不必額外索引。
在submissions集合，如果你的_id格式設置爲formID_userID得到所有提交所有你需要做的是：
db.submissions.find({'_id': '^formID'})
這裏的好處是錨定的正則表達式將使用_id_指數 - 所以它的效率。
一般參考和其他絆在此：大約有架構設計一些很好的演示 - 這是值得一試：
http://www.10gen.com/presentations/mongodb-tokyo-2012/basic-application-and-schema-design http://www.10gen.com/presentations/mongosv -2011 /方案設計原則和實踐
具有所有表單提交和表單模式作爲單個集合中的文檔。
你會想要避免這個（＃1）。這裏的簡單原因是提交的形式與模式不同。將這些混合在同一個集合中會使查詢更加困難。
對所有形式的模式單獨收集和所有表單提交
要澄清，這聽起來像你所建議的兩個集合：schema and submission`。
這是一個合乎邏輯的方法。您將收集一個小型schema集合和一個大型submission集合。
關鍵限制將是您針對該submission集合進行的查詢。您是否打算查詢「跨類型」？或者主要查詢是以「提交類型」爲中心的？
如果你最終包括對每個查詢「提交類型」，然後是有意義的......
有一個單獨的集合所有形式的模式，以及的所有提交創建一個新的集合形式爲每個模式。
其原因僅僅是索引。如果你有一個集合，你需要一個「類型」的索引。因此，通過製作單獨的集合，您可以保存索引。但是，如果您最終需要分片功能，則可能需要大量的集合才能管理。
當然，您可以通過與_id一起創造性地解決這個「額外索引」。 MongoDB有一個默認使用的自動生成的ObjectId，有點像自動增量ID。但是，您可以覆蓋此設置並創建一個更智能的_id，如submissionid_userid。
我的偏好是誠實的最後一個選項。但真的＃2 &＃3都是很好的選擇，真的只是代碼複雜性和管理複雜性的權衡問題。