現在、かなり単純な調査システムに取り組んでいます。データベーススキーマは単純になります。Survey
テーブルと__一対多の関係にあるQuestion
テーブルとAnswer
テーブルとの一対多の関係にあるPossibleAnswers
テーブルです。
最近、顧客は、前の質問に特定の回答をした人にのみ特定の質問を表示する機能が必要であることに気付きました(例タバコを購入しますか?あなたの好きなタバコのブランドは何ですか?、2番目の質問を非喫煙者に尋ねる意味はありません)。
これで、データベーススキーマの観点から、この条件付き質問を実装するための最良の方法は何だろうと思い始めました。 question A
には2つの可能な答えがあります:AとB、およびquestion B
はユーザーにのみ表示if答えはA
でしたか?
編集:私が探しているのは、要件に関するこれらの情報をデータベースに格納する方法です。私のSQLスキルが吸うように、データの処理はおそらくアプリケーション側で行われます;)
調査データベースの設計
最終更新日:2015年5月3日
図とSQLファイルが https://github.com/durrantm/survey で利用可能になりました
この(トップ)回答または任意の要素を使用する場合は、改善に関するフィードバックを追加してください!!!
これは、何千人もが行った本物のクラシックです。最初は常に「かなり単純」に見えますが、実際にはかなり複雑です。 Railsでこれを行うには、添付の図に示されているモデルを使用します。一部では複雑すぎるように思われるかもしれませんが、これらをいくつか構築したら、何年もの間、設計上の決定のほとんどが非常に古典的なパターンであり、最初は動的で柔軟なデータ構造によって最も適切に対処されていることに気付くでしょう。
以下の詳細:
キーテーブルのテーブルの詳細
answersテーブルは、ユーザーによる実際の応答をキャプチャするので重要です。 questionsではなく、question_optionsへのリンクに回答していることに気づくでしょう。これは意図的なものです。
input_typesは質問のタイプです。各質問は1種類のみです。すべてのラジオダイヤル、すべてのテキストフィールドなど。「含める?」に5つのラジオダイヤルと1つのチェックボックスがある場合は、追加の質問を使用します。オプションまたはそのような組み合わせ。ユーザービューの2つの質問に1つのラベルを付けますが、内部には2つの質問があり、1つはラジオダイヤル用、もう1つはチェックボックス用です。この場合、チェックボックスには1のグループがあります。
option_groupsおよびoption_choicesを使用すると、「共通」グループを構築できます。一例として、不動産アプリケーションでは、「物件は何歳ですか?」という質問があるかもしれません。 1-5 6-10 10-25 25-100 100+の範囲で回答が必要な場合があります
次に、たとえば、隣接する物件の築年数に関する質問がある場合、調査では上記の範囲を「再利用」して、同じoption_groupとオプションが使用されるようにします。
units_of_measureはそのとおりです。それがインチ、カップ、ピクセル、レンガなど何であれ、ここで一度定義できます。
参考:一般的な性質ですが、この上にアプリケーションを作成できます。このスキーマは、規則付きのRuby on Railsフレームワークに適しています各テーブルの主キーの「id」など。また、関係はすべてmany_to_manyまたはhas_manyのスルーが必要ない単純なone_to_manyです。おそらくhas.many:throughsおよび/または:delegatesを追加しますが、.multiple.chainingなしで簡単に個々の回答からsurvey_nameのようなものを取得します。
また、複雑なルールについて考え、質問テーブルに文字列ベースの条件フィールドを持ち、次のいずれかを受け入れ/解析することができます。
ここで、A(x)= yは「質問xの回答はyです」を意味し、C(x)は質問xの条件を意味します(デフォルトはtrue)...).
質問には順序フィールドがあり、条件がFALSEである質問をスキップして、1つずつ順番に進みます。
これにより、任意の複雑さの調査が可能になります。GUIはこれらを「シンプルモード」で自動的に作成し、ユーザーが方程式を直接入力できる「アドバンスモード」を可能にします。
1つの方法は、フィールドを含むテーブル「質問の要件」を追加することです。
アプリケーションでは、特定の質問をする前にこのテーブルを確認します。別のテーブルを使用すると、必要な回答を簡単に追加できます(「時々」の回答に別の行を追加するなど)。
個人的には、この場合、あなたが説明した構造を使用し、データベースをダムストレージメカニズムとして使用します。私はこれらの複雑で依存する制約をアプリケーション層に入れるのが好きです。
他のユーザーへの外部キーを使用してすべての質問に対して新しいテーブルを作成せずにこれらの制約を適用する唯一の方法は、T-SQLスタッフまたは他のベンダー固有のメカニズムを使用してデータベーストリガーを構築し、これらの制約を適用することです。
アプリケーションレベルでは、はるかに多くの可能性があり、移植が容易なので、そのオプションをお勧めします。
これがアプリの戦略を見つけるのに役立つことを願っています。