I've been thinking and learning a great deal about forms recently attempting to add advanced extensions towards the Spree ECommerce Platform: Monthly subscriptions, Occasions, Donations, and a myriad of Surveys.

Every example I've ever experienced (in blogs, within the docs, in screencasts, in source code, etc.) make forms from Models, however they never visit anything semi-structured or unstructured (or simply really dynamic). So you've forms like:

  1. Contact Page (User Model, maybe split into a previous address Model too)
  2. Registration Form (User Model, Account Model, Address Model, etc.)
  3. Blog Publish Form (Publish Model, Tag Model, etc.)
  4. Checkout Form (Shipping Model, Order Model, LineItem Model, etc.)

All individuals make sense: Those are the culmination of 10's of 1000's, millions even, of guy hrs. A lot of individuals have gradually abstracted individuals things lower into nearly universal "models" that may be saved right into a database table. Now all of us create models on their behalf making database tables on their behalf.

But you will find a lot of other activities that can not be boiled lower to individuals specific models. Such things as market research for any specific event, with form fields for example:

  1. Are you currently Pregnant?
  2. The number of kids have you got?
  3. Maybe you have been sick?
  4. What's your quickest mile?

When we began in order to save individuals items to the database in tables, we'd have 100s and a large number of database tables, one for every list of questions, or "survey".

So my thinking is, there's reached be some time you stop creating specific models such as the "Publish" and also the "Order" and begin just creating a "Form" or "Survey" model (Form ~ Survey ~ Questionnaire to some extent).

Everything could be boiled lower to those couple of models:

  1. Survey
  2. Question
  3. Answer
  4. ResponseSet (solutions to questions in survey)
  5. Response (specific response in reaction set)

And from individuals you can create any kind of "Form" you desired.

So my real question is essentially: When would you, within the most practical, day-to-day client projects, stop making forms with a lot of models inside them (a "Checkout" form is really a form for that "Order" essentially in Spree, but that simply requires 10 database models), and merely begin using Question/Answer or Area/Input or Key/Value? Practically?

I am just searching for something similar to "whenever we built our online teaching system, we did not finish up creating a lot of SomeTutorialModel objects which extend TutorialModel, because that would have mixed in many tables to the database. Rather, we simply used the Surveyor gem". Something along individuals lines :).

There isn't much available about this semi-structured kind of data, but lots when you are able boil it lower to something super concrete.

It appears when you used a Document Database, like CouchDB, you'd finish up having the ability to create a myriad of Model objects in ruby for instance, and may have them by helping cover their some clever view tricks. However with MySQL and also the-like, it appears insane.

Your real question is quite broad, and so i will rather than giving direct solutions mention these points:

1.) models frequently reflect the prospective (core) domain from the application, therefore the boundary between key/value and model is one of the domain

2.) AFAIK e.g. Google uses relational databases even going to store key/value data, to allow them to store everything as using document database

3.) all of your questions are essentially about modeling and abstraction, that is difficult to explain shortly or perhaps in general