最近,我一直在思考和学习很多有关表单,试图向Spree 电子商务平台添加高级扩展:订阅、活动、捐赠和各种调查。
我遇到的每个示例(在博客、文档、截屏视频、源代码等中)都使用模型制作表单,但它们从不涉及任何半结构化或非结构化(或只是真正动态的)。所以你有如下形式:
- 联系表(用户模型,也可能分为地址模型)
- 注册表(用户模型、账户模型、地址模型等)
- 博客帖子表单(帖子模型、标签模型等)
- 结帐表(运输模型、订单模型、LineItem 模型等)
所有这些都非常有意义:它们是数十万甚至数百万工时的结晶。很多人已经慢慢地将这些东西抽象成几乎通用的“模型”,可以保存到数据库表中。所以现在我们都为它们创建模型并为它们制作数据库表。
但是还有很多其他的事情不能归结为这些特定的模型。诸如针对特定事件的调查之类的事情,具有以下表单字段:
- 你怀孕了吗?
- 你有几个孩子?
- 你曾经生病过吗?
- 你最快的一英里是多少?
如果我们开始将这些东西以表格的形式保存到数据库中,我们将拥有 100 和 1000 多个数据库表,每组问题或“调查”都有一个。
所以我的想法是,你必须在某个时刻停止创建特定模型,如“帖子”和“订单”,而开始制作“表格”或“调查”模型(在某种程度上,表格 ~ 调查 ~ 问卷)。
一切都归结为这几个模型:
- 民意调查
- 问题
- 回答
- ResponseSet(对调查中问题的回答)
- 响应(响应集中的特定响应)
并且您可以从这些中创建您想要的任何类型的“表单”。
所以我的问题基本上是:在最实际的日常客户项目中,你什么时候停止制作包含一堆模型的表单(“结帐”表单基本上是 Spree 中的“订单”表单,但这很容易需要 10 个数据库模型),然后开始使用问题/答案或字段/输入或键/值?几乎?
我只是在寻找类似“当我们构建在线辅导系统时,我们最终并没有创建一堆扩展 TutorialModel 的 SomeTutorialModel 对象,因为那样会在我们的数据库中添加太多表。相反,我们只是使用了测量员宝石“。这些方面的东西:)。
这种半结构化类型的数据并不多,但是当您可以将其归结为超级具体的东西时,就会有很多。
似乎如果您使用文档数据库,例如 CouchDB,您最终将能够在 ruby 中创建各种模型对象,并且可以通过一些巧妙的视图技巧将它们弄出来。但是对于 MySQL 之类的,这似乎很疯狂。