調査のためのデータベース設計[終了]

回答をデータベースに保存する調査を作成する必要があります。これをデータベースに実装するための最良の方法は何ですか、特に必要なテーブルだけだと思います。調査にはさまざまな種類の質問が含まれています。例：コメントのテキストフィールド、複数選択の質問、および複数の回答を含む可能性のある質問（つまり、該当するものすべてをチェックしてください）。

私は2つの可能な解決策を考え出しました：

1. 各調査の提出に対する回答を含む巨大なテーブルを作成します。各列は、調査の回答に対応します。つまり、SurveyID、Answer1、Answer2、Answer3

   この調査には多くの質問があり、調査を変更する場合はあまり柔軟ではないため、これが最良の方法だとは思いません。

2. もう1つ考えたのは、質問テーブルと回答テーブルの作成です。質問表には、調査のすべての質問が含まれます。回答テーブルには、調査からの個々の回答が含まれ、各行が質問にリンクされます。

   簡単な例：

   tblSurvey：SurveyID

   tblQuestion：QuestionID、SurveyID、QuestionType、Question

   tblAnswer：AnswerID、UserID、QuestionID、Answer

   tblUser：UserID、UserName

   これに関する私の問題は、Answerテーブルをかなり巨大にする大量の回答が存在する可能性があることです。パフォーマンスに関しては、それがそれほど素晴らしいことかどうかはわかりません。

任意のアイデアや提案をいただければ幸いです。

あなたのモデル＃2は問題ないと思いますが、質問と作成済みの回答（提供された回答）を格納し、それらを別の調査で再利用できる、より複雑なモデルを見ることができます。

-1つの調査には多くの質問が含まれる可能性があります。1つの質問は、多くの調査で（再）使用できます。
-1つの（既製）回答を多くの質問に提供できます。1つの質問で多くの回答を提供できます。質問は、異なる調査で提供される異なる回答を持つことができます。さまざまな調査のさまざまな質問に回答を提供できます。デフォルトの「その他」の回答があり、他の人を選択すると、その回答がAnswer.OtherTextに記録されます。
-1人は多くの調査に参加でき、1人は調査の特定の質問に1回だけ回答できます。

私のデザインを以下に示します。

最新の作成スクリプトはhttps://gist.github.com/durrantm/1e618164fd4acf91e372にあります

スクリプトとmysql workbench.mwbファイルは、https：//github.com/durrantm/surveyからも入手でき
ます。

間違いなくオプション＃2です。また、現在のスキーマを見落としているかもしれません。別のテーブルが必要かもしれません。

+-----------+
| tblSurvey |
|-----------|
| SurveyId  |
+-----------+

+--------------+
| tblQuestion  |
|--------------|
| QuestionID   |
| SurveyID     |
| QuestionType |
| Question     |
+--------------+

+--------------+
| tblAnswer    |
|--------------|
| AnswerID     |
| QuestionID   |
| Answer       |
+--------------+

+------------------+
| tblUsersAnswer   |
|------------------|
| UserAnswerID     |
| AnswerID         |
| UserID           |
| Response         |
+------------------+

+-----------+
| tblUser   |
|-----------|
| UserID    |
| UserName  |
+-----------+

各質問には、ユーザーが選択できる設定された数の回答が含まれている可能性があり、実際の回答は別のテーブルで追跡されます。

データベースは大量のデータを格納するように設計されており、ほとんどの場合非常に適切にスケーリングされます。スペースを節約するためだけに、通常のフォームを使用する必要はありません。

一般的なルールとして、ユーザーが変更できる可能性があるもの（調査への質問の追加など）に基づいてスキーマを変更することは、かなり臭いと見なす必要があります。特に大量のデータを処理する場合に適切な場合もありますが、詳細に入る前に何を理解しているかを把握します。アンケートごとに「回答」テーブルを用意するだけで、質問の追加または削除に非常にコストがかかる可能性があります、そして質問にとらわれない方法で分析を行うことは非常に困難です。

私はあなたの2番目のアプローチが最善だと思いますが、スケールに関する多くの懸念があると確信している場合、過去に私のために働いてきた1つのことはハイブリッドアプローチです。

1. 2で説明したように、質問ごとの応答を格納するための詳細な応答テーブルを作成します。このデータは通常、アプリケーションから直接照会されませんが、レポートテーブルの要約データの生成に使用されます。また、このデータを何らかの形でアーカイブまたは消去する方法を実装することもできます。
2. 必要に応じて、1からの応答テーブルも作成します。これは、ユーザーが結果の簡単な表を見たいときにいつでも使用できます。
3. レポート目的で実行する必要がある分析については、ジョブをスケジュールして、1のデータに基づいて追加の要約データを作成します。

これは絶対に実装する作業がはるかに多いので、このテーブルが大規模な問題に遭遇することを確実に知らない限り、私は本当にこれを勧めません。

2番目のアプローチが最適です。

さらに正規化したい場合は、質問タイプのテーブルを作成できます

簡単なことは次のとおりです。

• データベースを配置し、デフォルトですべてCにではなく、独自のディスクにログオンする
• 必要なサイズのデータ​​ベースを作成して、データベースの拡大中に一時停止しないようにします。

SQL Serverテーブルには数千万行のログテーブルがあります。

いいえ2はうまく見えます。

カラムが4つしかないテーブルの場合、数百万行でも問題ありません。もちろん、これは使用しているデータベースによって異なります。SQL Serverのようなものであれば問題ありません。

おそらく、tblAnswerテーブルのQuestionIDフィールドにインデックスを作成する必要があります。

もちろん、使用しているデータベースと推定ボリュームを指定する必要があります。

簡単な調査では、かなり完全に見えます。顧客がテキストボックスを介して意見を提供できる「オープンバリュー」のテーブルを追加することを忘れないでください。そのテーブルを外部キーと回答にリンクし、パフォーマンスのためにすべてのリレーショナル列にインデックスを配置します。

2番は正解です。パフォーマンスの問題を検出するまでは、正しい設計を使用してください。ほとんどのRDBMSでは、幅が狭いが非常に長いテーブルでは問題が発生しません。

大きなAnswerテーブルを用意すること自体は問題ではありません。インデックスと制約が明確に定義されている限り、問題ありません。2番目のスキーマは私には良さそうです。

適切なインデックスがあれば、2番目のソリューションは正規化され、従来のリレーショナルデータベースシステムに適しています。

どれほど巨大かはわかりませんが、問題なく数百万回の回答が得られるはずです。

フォーム全体をJSON文字列として保存することもできます。

要件については不明ですが、このアプローチは状況によっては機能します。