私は最近、Spree Eコマースプラットフォームに高度な拡張機能（サブスクリプション、イベント、寄付、およびあらゆる種類の調査）を追加しようとしているフォームについて多くのことを考え、学んでいます。
私がこれまでに遭遇したすべての例（ブログ、ドキュメント、スクリーンキャスト、ソースコードなど）は、モデルからフォームを作成しますが、半構造化または非構造化（または本当に動的）なものには決して行きません。したがって、次のようなフォームがあります。
- お問い合わせフォーム（ユーザーモデル、住所モデルにも分割される場合があります）
- 登録フォーム（ユーザーモデル、アカウントモデル、アドレスモデルなど）
- ブログ投稿フォーム（投稿モデル、タグモデルなど）
- チェックアウトフォーム（出荷モデル、注文モデル、LineItemモデルなど）
これらはすべて完全に理にかなっています。これらは、数万、数百万の工数の集大成です。多くの人々がそれらをゆっくりと抽象化して、データベーステーブルに保存できるほぼ普遍的な「モデル」にしています。だから今、私たちは皆、それらのモデルを作成し、それらのデータベーステーブルを作成します。
しかし、それらの特定のモデルに要約できないものは他にもたくさんあります。次のようなフォームフィールドを使用した、特定のイベントの調査など。
- あなたが妊娠している？
- 子供は何人いますか？
- 病気になったことがありますか？
- あなたの最速のマイルは何ですか？
それらをテーブルのデータベースに保存し始めた場合、質問のセットごとに1つずつ、つまり「調査」として、数百から数千のデータベーステーブルが作成されます。
だから私の考えでは、「投稿」や「注文」などの特定のモデルの作成をやめて、「フォーム」または「調査」モデルの作成を開始する必要があります（フォーム〜調査〜アンケートはある程度） ）。
すべてはこれらのいくつかのモデルに要約されます：
- 調査
- 質問
- 答え
- ResponseSet（調査の質問への回答）
- 応答（応答セット内の特定の応答）
そしてそれらからあなたはあなたが望むどんなタイプの「フォーム」も作成することができました。
だから私の質問は基本的に：あなたは、最も実用的な日常のクライアントプロジェクトで、モデルの束を含むフォームの作成をいつ停止しますか（「チェックアウト」フォームは基本的にSpreeの「注文」のフォームです） 、しかしそれは簡単に10のデータベースモデルを必要とします）、そして質問/回答またはフィールド/入力またはキー/値の使用を開始しますか？特に？
「オンライン家庭教師システムを構築したとき、データベースに追加されるテーブルが多すぎるため、TutorialModelを拡張するSomeTutorialModelオブジェクトの束を作成することはできませんでした。代わりに、サーベイヤーの宝石を使用しました」。それらの線に沿った何か:)。
この半構造化されたタイプのデータについてはそれほど多くはありませんが、それを非常に具体的なものにまとめることができる場合はたくさんあります。
CouchDBのようなドキュメントデータベースを使用した場合、たとえばRubyですべての種類のModelオブジェクトを作成できるようになり、巧妙なビュートリックでそれらを取得できるようになります。しかし、MySQLなどでは、それは非常識に思えます。