最高のもの：レコードごとに1つのテーブルまたはすべてのレコードが外部キーにリンクされた1つのテーブル？

Question

私は、ユーザーがさまざまなフォーム（アンケート）を作成して記入できるアプリケーションを用意しています。 （紙の代用品なので）。

は、ここで私はアプリで使用している現在のモデルです：

Table 1) 
+-------------------------+ 
|  SURVEYS TABLE  | 
+----+------+-------------+ 
| ID | name | description | 
+----+------+-------------+ 

Table 2) 
+-----------------------------------+ 
|  $[name_of_the_survey]  | 
+----+-------+------+-------+-------+ 
| ID | field | type | value | items | 
+----+-------+------+-------+-------+ 


Table 3) 
+--------------------------------------+ 
| $[name_of_the_survey] _records | 
+----+---------------------------------+ 
| ID | columns specific to each survey | 
+----+---------------------------------+ 

ので、基本的にユーザーがアンケートを作成するときに、プログラムが調査テーブルのレコードを挿入して、2つのテーブルを作成：

をストアされるレコードのテーブルテーブル（3）のフィールドのテーブル（2）。カラムはテーブル（2）の行に対応します。

これは機能しますが、いくつかの制限があります。たとえば、テーブル（2）にフィールドを追加する場合、テーブル（3）の内容を読み込み、仮想テーブルに保存し、前のテーブル（3）を削除して新しいテーブルを作成する必要があります。これは、テーブル（3）に大量のレコードがある場合のパフォーマンス上の問題です。

私の質問は...より良いデータベース設計はありますか？

Answer 1

調査ごとに別のテーブルを使用すると、データベースの使用がほぼ無効になります。あなたはファイルに結果を保存することもできます。

ただし、調査定義、調査質問、アンケート回答の3つのテーブルが必要です。それは

Surveys: 
ID; name; description 

Questions: 
ID; text; surveyID 

Answers: 
ID; answer; questionID 

あなたが列挙された答えを処理するために、そこから複雑さを追加することができ

...

Surveys: 
ID; name; description 

Questions: 
ID; text; surveyID 

Choices: 
ID; choice; questionID 

Answers: 
ID; choiceID 

は、あなたが次に高いレベルに集約するために、各テーブル間の関係を使用して...このような何かを見て選択したステートメントのソースを抽象化せずに、追加するモデルの質問、調査、その他の属性から結果を得ることができます。これにより、ユーザまたは測量組織ごとの回答をスキーマに追加した後で集計することもできます。各調査に独自のテーブル構造がある場合、調査全体でデータを集約することは、アプリケーションが成長するにつれて非常に非実用的になります。あなたは上記の http://en.wikipedia.org/wiki/Database_normalization#Normal_forms

を見てみてみてください

Answer 2

は、一般的に各DBを改善する、非常に形式的な方法であり、ステップのいくつかは、あなたのDBに関連しています。私はそれがすべてのIDフィールドと少し混乱していると思う。それぞれに本当に必要ですか？測量名はユニークではありませんか？

調査データフィールドは非常にユニークであることを意味しています。個人的には、各調査をファイルに並べ替え、それに標準形式を与えます。一度に全調査を読む傾向があるのであれば、悪い考えではありません。私は、データのソートや選択、選択が必要な場合にのみDBを使用します。