ユーザーがフィールドを定義できる場合のスキーマ設計

最初のスキーマは、2つのうちのより良い選択です。この時点では、パフォーマンスの問題について心配する必要はありません。優れた、柔軟で拡張可能なデザインを作成することを心配します。データをキャッシュしてクエリを高速化するために、後で実行できるさまざまなトリックがあります。実現すらできない可能性のあるパフォーマンスの問題を解決するために、柔軟性の低いデータベーススキーマを使用することは、悪い決断です。

さらに、多くの（おそらくほとんどの）調査結果は定期的かつ少数の人（イベント主催者、管理者など）によってのみ表示されるため、すべての結果についてデータベースに常にクエリを実行することはありません。そして、あなたがそうだったとしても、パフォーマンスは素晴らしいでしょう。とにかく、おそらく結果をページングするでしょう。

最初のスキーマははるかに柔軟です。デフォルトでは、名前や住所などの質問を含めることができますが、匿名の調査の場合は、それらを作成することはできません。調査の作成者が500のうち3つの質問に対する全員の回答のみを表示したい場合、それは非常に単純なSQLクエリです。カスケード削除を設定して、調査が削除されたときに回答と質問を自動的に削除することができます。このスキーマを使用すると、統計の生成もはるかに簡単になります。

これは、提供したスキーマのわずかに変更されたバージョンです。どのデータ型がどこに行くのか理解できると思います:-)

    surveys
      survey_id (index)
      title

    questions
      question_id (index, auto increment)
      survey_id (link to surveys->survey_id)
      question

    responses
      response_id (index, auto increment)
      survey_id (link to surveys->survey_id)
      submit_time

    answers
      answer_id (index, auto increment)
      question_id (link to questions-question_id)
      answer