我一直在思考和学习很多关于最近尝试向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和类似的，它似乎很疯狂。