アンケートデータベースの設計-どちらの方法が良いですか?


15

長いhtmlページが1つあり、いくつかの質問セットが小さなセクション(1ページに約15のサブセクション)に分かれています。質問の合計は約100の質問です。入力、複数選択、チェックボックス、ラジオボタン、テキストエリア、およびファイルのアップロード。1つの質問には、チェックボックスのグループ、選択リストのグループ、複数選択のグループ、またはそれらすべてを1つの回答にまとめたもののいずれかから取得した多くの回答を含めることができます。私はこのデータベース設計を以下で使用するつもりだったが、結局のところそれは良いアプローチではないことがわかった。

  1. 1人の顧客は、1組の質問(100の質問につき1人の顧客)しか持てません。
  2. 古いアプローチでは、データベースに疑問を抱かず、代わりにPHPコーディングで定数として割り当てます。問題は、PHPの質問をデータベースの回答と同期させるために比較する必要があることです。1つの質問がPHPから変更/削除/移動された場合、質問データベースの回答と一致させるために間違いなく迷子になります。より良い解決策?
  3. フォームの複数の要素から取得した複数の回答を1つの回答として1つのフィールドに保持できますか?このフィールドを取得して、フォームで顧客が表示するために再度表示するにはどうすればよいですか?
  4. 下のどのオプションに行くべきですか?

オプション1:古いアプローチ(1テーブル)

表:アンケート

  • ID(PK)
  • 顧客ID
  • 状態
  • A1
  • A2
  • A3
  • A100

オプション2:新しいアプローチ(2つのテーブル)

表:質問

  • QID(PK)
  • 質問(varchar)

表:回答

  • 援助(PK)
  • 顧客ID
  • QID(int)
  • 回答(varchar)

またはオプション3?


アプリケーションに関する詳細情報を追加してください。-アンケートは動的に作成されますか?IE:このアンケートにはこれらの質問があり、別のアンケートにはこれらの他の質問があります。-アンケートの質問は動的ですか?IE:顧客は後で新しい質問を追加できます。動的システムか静的システムかに関係なく、1:1の質問と回答の結果をDBの1:Mの質問と回答とは異なる方法で保存する必要があります。
ザンボニーリ

それぞれはい、いいえ(動的な質問は第2フェーズの後半かもしれませんが、今はそうではありません。)
モジュール式

入力、複数選択、チェックボックス、ラジオボタン、テキストエリア、ファイルのアップロードなどさまざまで、ファイルのアップロードは広すぎて役に立たないのでこの100の質問を終了することに投票しました。
エヴァンキャロル

回答:


17

アンケートをハードコーディングしないでください。リレーショナルデータベースまたはxmlファイルを使用します。私は次の表を提案します

  • Questionnaire:アンケートの一般的な説明。タイトル、調査名、アンケートのリリース日、バージョンなど。

  • Section:アンケートの構成セクション。セクションの番号、セクションのタイトル、説明。

  • Question:セクションに属する質問。質問の番号、質問テキスト、説明、質問タイプ(テキスト、複数選択など)。

  • Question_Choice:単一のチェックボックス、ラジオボタンなどに対応する質問に属する可能な回答。選択のテキスト、選択番号、順序。

  • Respondent:質問に答える人。個人データ、ユーザー番号。

  • Interview:1人の回答者と1つのアンケートに属するインタビューまたはテストまたはアンケート(アンケートの性質に依存)。回答者が常に1つのアンケートのみに回答できる場合(または調査が匿名の場合)、このテーブルは廃止され、回答者テーブルとマージできます。面接日(またはテスト日または調査日)、面接官(該当する場合)。

  • Answer:1つのインタビュー(または上記の回答者)と1つの質問に属する回答。回答テキスト(テキストタイプの質問の場合)、選択(ラジオボタンの場合)。

  • Answer_Choice:複数の選択肢をチェックできる場合、1つの回答と1つのQuestion_Choiceに属する選択肢。

これは非常に正規化されたアプローチです。ただし、必要に応じて、選択肢を1つの文字列に連結するか、ビットパターンとして保存するか、他の方法で単純化するかを決定できます。


6

いくつかのテーブルが必要です。

1-質問(質問ID、入力タイプ、表示、質問タイプ、質問テキスト、予想される回答...)

2-回答(質問ID、ユーザーID、アクティビティID、回答...)

3-ユーザー(ユーザーID、ユーザー名......)

4-質問/回答アクティビティを保持するテーブル(アクティビティID、データ/時間、ユーザーID)

また、各アクティビティに適用する必要のある質問を指定するテーブルを用意することもできます。ユーザーごとにグループ化するか、質問コレクションをグループ化します。外部/主キーは、複数のテーブルで同じ名前を持つ列であり、インデックスを作成する必要があります。

この構造を使用する場合、スキーマまたはプレゼンテーションコードを変更せずに質問またはユーザーを追加したり、回答を変更したりすることができます-プレゼンテーションコードが実行時に動的に作成されることを確認します-レコードを追加するだけです適切な場所で。

このアプローチは、ハードコーディングされたアプローチよりも最初に開発するのに時間がかかる場合がありますが、動作を変更するためにデータを変更するだけでよいため、保守がはるかに簡単になります。

(ヒント、プレゼンテーションレイヤーを作成するには、適切な質問を表示するクエリが必要です。次に、この結果セットをループし、画面に質問を表示するメソッドを呼び出します。選択するメソッドは、その質問のプレゼンテーション[テキストボックス、ラジオグループなど])


+1表#4についてはわかりませんが、全体的に良い答えです。特に、単数形のテーブル名から複数形、つまり質問>>質問への変更が気に入っています。
リーリッフェル
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.