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 回答