At What Point Does a Form Lose its "Model-ness" and Become a Document?

I have been thinking and learning a lot about forms lately trying to add advanced extensions to the Spree ECommerce Platform: Subscriptions, Events, Donations, and all kinds of Surveys.

Every example I have ever encountered (in blogs, in the docs, in screencasts, in source code, etc.) make forms out of Models, but they never go to anything semi-structured or unstructured (or just really dynamic). So you have forms like:

1. Contact Form (User Model, maybe divided into an Address Model too)
2. Registration Form (User Model, Account Model, Address Model, etc.)
3. Blog Post Form (Post Model, Tag Model, etc.)
4. Checkout Form (Shipping Model, Order Model, LineItem Model, etc.)

All of those make perfect sense: They are the culmination of 10's of thousands, millions even, of man hours. Tons of people have slowly abstracted those things down into nearly universal "models" that could be saved into a database table. So now we all create models for them and make database tables for them.

But there are so many other things that can't be boiled down to those specific models. Things like a survey for a specific event, with form fields such as:

1. Are you Pregnant?
2. How many kids do you have?
3. Have you ever been sick?
4. What's your fastest mile?

If we s开发者_开发问答tarted to save those things to the database in tables, we would have 100s and 1000s of database tables, one for each set of questions, or "survey".

So my thinking is, there's got to be some point at which you stop creating specific models like the "Post" and the "Order" and start just making a "Form" or "Survey" model (Form ~ Survey ~ Questionnaire to some degree).

Everything would be boiled down to these few models:

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

And from those you could create any type of "Form" you wanted.

So my question is basically: When do you, in the most practical, day-to-day client projects, stop making forms with a bunch of models in them (a "Checkout" form is a form for the "Order" basically in Spree, but that easily requires 10 database models), and just start using Question/Answer or Field/Input or Key/Value? Practically?

I'm just looking for something like "when we built our online tutoring system, we didn't end up creating a bunch of SomeTutorialModel objects which extend TutorialModel, because that would've added too many tables to our database. Instead, we just used the Surveyor gem". Something along those lines :).

There's not much out there on this semi-structured type of data, but lots when you can boil it down to something super concrete.

It seems that if you used a Document Database, like CouchDB, you'd end up being able to create all kinds of Model objects in ruby for example, and could get them out with some clever view tricks. But with MySQL and the-like, it seems insane.

Your question is quite broad, so I will instead of giving direct answers mention these points:

1.) models often reflect the target (core) domain of the application, so the boundary between key/value and model is about the domain

2.) AFAIK e.g. Google uses relational databases even to store key/value data, so they can store everything as using document database

3.) all your questions are basically about modeling and abstraction, which is hard to explain shortly or in general