database - 表单在什么时候丢失其 "Model-ness"并成为文档？

Question

我最近一直在思考和学习很多关于表单的知识，试图为 Spree ECommerce Platform 添加高级扩展。 :订阅、事件、捐赠和各种调查。

我遇到的每个例子(在 blogs 中，在 docs 中，在 screencasts 中，在 source code 中，等等)用 Models 制作表格，但他们从不使用任何半结构化或非结构化(或只是真正动态的)。所以你有这样的形式:

1. Contact Form(用户模型，也可能分为地址模型)
2. 注册表(用户模型、账户模型、地址模型等)
3. 博客帖子表单(帖子模型、标签模型等)
4. 结帐表格(运输模型、订单模型、订单项模型等)

所有这些都非常有道理:它们是数十万、甚至数百万工时的结晶。很多人慢慢地将这些东西抽象成几乎通用的“模型”，可以保存到数据库表中。所以现在我们都为他们创建模型并为他们制作数据库表。

但是还有很多其他事情不能归结为那些特定的模型。诸如针对特定事件的调查之类的事情，表单字段如下:

1. 你怀孕了吗？
2. 你有几个 child ？
3. 你生过病吗？
4. 你最快的英里数是多少？

如果我们开始将这些东西保存到表中的数据库中，我们将有 100 和 1000 的数据库表，每组问题或“调查”都有一个表。

所以我的想法是，必须在某个时刻停止创建特定模型，例如“邮寄”和“订单”，而开始制作“表格”或“调查”模型(表格 ~ 调查 ~ 问卷在某种程度上)。

一切都可以归结为这几个模型:

1. 调查
2. 问题
3. 回答
4. ResponseSet(调查中问题的答案)
5. Response(响应集中的特定响应)

您可以从中创建您想要的任何类型的“表单”。

所以我的问题基本上是:在最实际的日常客户项目中，您什么时候停止制作其中包含一堆模型的表格(“结帐”表格是“订单”表格)基本上在 Spree 中，但这很容易需要 10 个数据库模型)，然后开始使用问题/答案或字段/输入或键/值？实际上？

我只是在寻找类似“当我们构建在线辅导系统时，我们并没有最终创建一堆扩展 TutorialModel 的 SomeTutorialModel 对象，因为那样会向我们的数据库添加太多表。相反，我们刚刚使用了 Surveyor gem “。类似的东西 :).

这种半结构化类型的数据并不多，但当您可以将其归结为 super 具体的东西时，就会有很多。

似乎如果您使用文档数据库，例如 CouchDB，您最终将能够在 ruby​​ 中创建各种模型对象，并且可以用一些 clever view tricks 将它们取出来.但是对于 MySQL 等，这似乎很疯狂。

Answer 1

你的问题很宽泛，所以我不会给出直接的答案，而是提及以下几点:

1.) 模型往往反射(reflect)了应用的目标(核心)领域，所以键/值和模型之间的边界是关于领域的

2.) 据我所知，例如Google 甚至使用关系数据库来存储键/值数据，因此他们可以像使用文档数据库一样存储所有内容

3.) 你所有的问题基本上都是关于建模和抽象的，这很难在短期内或笼统地解释