調査データベースの設計
最終更新日:2015年5月3日
ダイアグラムとSQLファイルがhttps://github.com/durrantm/surveyで利用可能になりました

この(一番上の)回答または任意の要素を使用する場合は、改善に関するフィードバックを追加してください!!!
これは何千人もの人によって行われる本当の古典です。それらは、最初は常に「かなり単純」に見えますが、実際にはかなり複雑です。Railsでこれを行うには、添付の図に示されているモデルを使用します。一部の人にとっては非常に複雑に見えると思いますが、これらのいくつかを構築すると、何年にもわたって、設計上の決定のほとんどが非常に古典的なパターンであり、動的で柔軟なデータ構造によって最もよく対処されることに気付くでしょう。最初。
以下の詳細:
キーテーブルのテーブルの詳細
答え
回答テーブルは、ユーザーによる実際の回答をキャプチャするため、非常に重要です。回答は質問ではなく、question_optionsへのリンクであることに気付くでしょう。これは意図的なものです。
input_types
input_typesは、質問のタイプです。各質問は1つのタイプのみにすることができます。たとえば、すべてのラジオダイヤル、すべてのテキストフィールドなどです。(たとえば)5つのラジオダイヤルと1つのチェックボックスが「含める」の場合は、追加の質問を使用します。オプションまたはそのような組み合わせ。ユーザービューで2つの質問に1つのラベルを付けますが、内部には2つの質問があります。1つはラジオダイヤル用、もう1つはチェックボックス用です。この場合、チェックボックスには1のグループが含まれます。
option_groups
option_groupsとoption_choicesを使用すると、 「共通」グループを作成できます。一例として、不動産アプリケーションでは、「不動産は何歳ですか?」という質問があるかもしれません。答えは次の範囲で望まれるかもしれません:1-5 6-10 10-25 25-100 100+
次に、たとえば、隣接する不動産の年齢について質問がある場合、調査では上記の範囲を「再利用」して、同じoption_groupとoptionsが使用されるようにします。
測定単位
units_of_measureはその通りです。インチ、カップ、ピクセル、レンガなど、ここで一度定義できます。
参考:一般的な性質ですが、この上にアプリケーションを作成できます。このスキーマは、各テーブルの主キーに「id」などの規則を使用するRubyOnRailsフレームワークに最適です。また、関係はすべて単純なone_to_manyであり、many_to_manyまたはhas_manyスルーは必要ありません。個々の回答からsurvey_nameのようなものを.multiple.chainingなしで簡単に取得するために、おそらくhas_many:throughsや:delegatesを追加します。