3

最近，我一直在思考和学习很多有关表单，试图向Spree 电子商务平台添加高级扩展：订阅、活动、捐赠和各种调查。

我遇到的每个示例（在博客、文档、截屏视频、源代码等中）都使用模型制作表单，但它们从不涉及任何半结构化或非结构化（或只是真正动态的）。所以你有如下形式：

  1. 联系表（用户模型，也可能分为地址模型）
  2. 注册表（用户模型、账户模型、地址模型等）
  3. 博客帖子表单（帖子模型、标签模型等）
  4. 结帐表（运输模型、订单模型、LineItem 模型等）

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

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

  1. 你怀孕了吗？
  2. 你有几个孩子？
  3. 你曾经生病过吗？
  4. 你最快的一英里是多少？

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

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

一切都归结为这几个模型：

  1. 民意调查
  2. 问题
  3. 回答
  4. ResponseSet（对调查中问题的回答）
  5. 响应（响应集中的特定响应）

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

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

我只是在寻找类似“当我们构建在线辅导系统时，我们最终并没有创建一堆扩展 TutorialModel 的 SomeTutorialModel 对象，因为那样会在我们的数据库中添加太多表。相反，我们只是使用了测量员宝石“。这些方面的东西:)。

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

似乎如果您使用文档数据库，例如 CouchDB，您最终将能够在 ruby​​ 中创建各种模型对象，并且可以通过一些巧妙的视图技巧将它们弄出来。但是对于 MySQL 之类的，这似乎很疯狂。

4

1 回答 1

0

您的问题非常广泛，因此我不会直接给出答案，而是提及以下几点：

1.）模型通常反映应用程序的目标（核心）领域，因此键/值和模型之间的边界是关于领域的

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

3.）你所有的问题基本上都是关于建模和抽象的，这很难简单或概括地解释

于 2010-09-09T22:58:05.397 回答