5000レコードのテーブルと、5つのトピックのリストを含む別のテーブルがあるとします。各トピックは、より大きなテーブルの1000レコードに関連付けられています。各コメントには、トピックテーブルへの外部キーである「トピック」フィールドがあります。
たとえば、データベースにすべてのユーザーのコメントがWebサイトに保存されているとします。トピックAに1000件、トピックBに1000件のコメントがあります...
特定のトピックに関するすべてのコメントを取得する場合は、可能な5000行から正しい1000行を取得するクエリを作成する必要があります。代わりに5つのテーブルを作成し、各テーブルに特定のトピックに関するコメントのみを格納するとします。
おそらく40を超えるトピックが存在しないと仮定すると、これはデータベース設計への賢明なアプローチですか？明らかな欠点はわかりませんが、クエリ結果が速くなるようです。
フランクシュミットは正しいです。
私はあなたがリレーショナルデータベースの経験があまりないことを前提としています-それらを読む価値があります（JoeCelkoは役立つかもしれない2冊の本を持っています）。あなたが説明する問題は、実際にはRDBMSが解決するように設計された重要な問題の1つです。これは、インデックス、外部キー、およびSQLを使用して行います。これらの問題を解決する標準的な方法があり、ほとんどの開発者はそれらに精通しているため、RDBMSを使用している場合は、これについて学ぶことをお勧めします。
これらのツールでは不十分な場合や、実際のパフォーマンスの問題により、「標準」ではないソリューションを設計しなければならない場合があります。ただし、5000レコードでは発生しない傾向があります。これらの解決策は、1つの制約を解決する可能性があるため、問題があることを証明できる場合にのみ検討する必要がありますが、通常は他の問題を犠牲にします。
したがって、5000レコードデータベースが遅すぎることを証明でき、他のすべてを最適化し、より多くのハードウェアを投入し、キャッシュし、オプションを使い果たした場合は、説明した方法でテーブルを分割することを検討してください。それはメンテナンスの頭痛の種を生み出し、データベースアクセスコードは読みにくくなります-そしてプロジェクトを手にした新しい開発者はWTFの瞬間を持ち、トレーニングとドキュメントを必要とします。
その道を下ってはいけません。速くはなりませんが、すぐにメンテナンスの悪夢になります。
すべてのコメントを1つのテーブルに入れ、インデックス付きの外部キーを追加するだけで問題ありません（5000レコードは非常に少量のデータですが、ところで、RDBMSシステムは通常問題なく数百万行を処理します）。