スキーマの設計は、少なくともこの投稿と前回の投稿で提供された情報に基づいて、私には問題ないように見えます。ベスト プラクティスは、正規化された設計から始めて、クエリの最適化が必要と思われる場所を非正規化することです。データベースが大規模になったり、トランザクションの頻度が高くなったりすることはないと思います。そのため、パフォーマンスは問題にならないはずなので、正規化された設計に固執します。経験則として、4 つ以上のテーブルを結合するクエリを作成する必要がある場合 (少なくとも SQL Server では)、非正規化は価値があるかもしれませんが、このスキーマ設計でそれが起こっていることは実際にはわかりません。
質問で示唆しているように、DataCollection テーブル内に両方の属性を含めることで、Form テーブルと Sample テーブルは非正規化の候補になる可能性がありますが、これは、Form と Sample が持つ他の属性の数と、両方に共通する属性の数によって異なります。
私が提供する1つのヒントは、フォームテーブルに短い文字列である主キーを与えることを検討することです.かなり標準的なフォームがあると仮定すると、テーブルを閲覧するときに少し楽になります(たとえば、HMRCフォームP45、P60などに少し似ています) . または空港コード LHR、JFK など)、特定の int ID が参照するフォームを覚えておくために他のテーブルと結合し続ける必要がないためです。CHAR(3) フィールドは、INT よりも使用するストレージも少なくなります。これは、DataCollectionType などの他のテーブルに適用される場合があります。しかし、これはおそらく個人的な好みの問題です。
前回の投稿での議論から、我々が話した DataFrequency テーブルは、おそらく DataCollection テーブルへの many-1 リンクであるはずです。おそらく、DataCollectionIntervals の方が適切な名前かもしれません。
設計で考慮すべきもう 1 つの点は、頻繁にアクセスされるテーブルが垂直方向の分割からメリットを得られるかどうかです。つまり、テーブルに幅の広い行がある場合、つまり、VARCHAR(MAX) のような頻繁にアクセスされない属性やストレージを大量に消費する属性は、このテーブルを含むクエリのパフォーマンスを大幅に向上させることができる 1-1 リンクで別のテーブルに分割できます。 . しかし、私が言っているように、SQL Server のようなものを使用することを計画し、想定しているデータベースのサイズに関して、パフォーマンスが問題になるとは思えません。
最後に 1 つ... フォームの構造は、スキーマが現在示すよりも少し複雑になる可能性があります。たとえば、フォームは通常、いくつかのセクションに分割され、必要な質問の種類は、複数選択、テキスト、分岐、条件付きなど、非常に複雑になる可能性があります。また、フォームは異なるバージョンに存在する可能性があります (アクティブ フラグを使用して、フォーム テーブルで現在アクティブなバージョンを識別します)。XML でアンケートを設計するために自分自身で queXML を使用することを検討しましたが、必要なものには少しやり過ぎだと判断したため、データベースにインポートできる独自の単純な XML スキーマを使用することにしました。
