我一直在思考和學習很多關於最近嘗試向Spree ECommerce Platform添加高級擴展的表單：訂閱，事件，捐贈和各種調查。在什麼時候表格會失去「模範」併成爲文檔？
我曾經遇到的每一個例子（blogs，在docs，在screencasts，在source code等），使形式出Models，但他們從來沒有去任何半結構化或非結構化（或只是真的動態）。所以，你有喜歡的形式：
- 聯繫表（用戶模型，也許分成一個地址型號太）
- 登記表（用戶模型，賬戶模型，地址模型等）
- 博客文章形式（郵政型號，標籤型號等）
- 檢驗表（通航模式，訂購模式，LineItem的型號等）
所有這些的非常清楚了：他們是成千上萬的10年代的巔峯之作，數百萬甚至是工時。許多人已經慢慢將這些東西抽象成幾乎可以保存到數據庫表中的通用「模型」。所以現在我們都爲它們創建模型併爲它們創建數據庫表。
但還有很多其他的東西不能歸結爲這些特定的型號。諸如針對特定事件的調查，例如表格字段：
- 您是否懷孕？
- 你有幾個孩子？
- 你有沒有生病過？
- 你最快的一英里是什麼？
如果我們開始的那些東西保存到表的數據庫，我們將有100秒和數據庫表，每個組問題，或「調查」的1000。所以我的想法是，你必須停止創建特定模型，比如「Post」和「Order」，並開始製作一個「Form」或「Survey」模型（Form〜Survey〜問卷在一定程度上）。
一切都將歸結爲這幾個型號：
- 調查
- 問題
- 回答
- ResponseSet（答案在調查問題）
- 響應（具體響應響應集）
而從那些y你可以創建你想要的任何類型的「表單」。
所以我的問題基本上是：你在什麼時候，在最實際的日常客戶項目中，停止製作帶有一堆模型的表單（「Checkout」表單是「訂單「基本上在Spree中，但這很容易需要10個數據庫模型），並開始使用Question/Answer或Field/Input或Key/Value？幾乎？
我只是在尋找類似於「當我們構建我們的在線輔導系統時，我們並沒有最終創建一堆擴展TutorialModel的SomeTutorialModel對象，因爲這會將太多的表添加到我們的數據庫中。相反，我們只使用了Surveyor gem「。沿着這些線:)東西。
在這個半結構化的數據類型上沒有太多的東西，但是很多時候你可以將它歸結爲超級具體的東西。
看來，如果你使用了一個文檔數據庫，比如CouchDB，你最終可以在ruby中創建各種模型對象，例如可以用clever view tricks來獲得它們。但是對於MySQL和類似的，它似乎很瘋狂。