列数の多い単一のテーブルと列数の少ない複数のテーブル

ソーシャルネットワークのウェブサイトに適したデータベース設計は何でしょうか？列が多く行が少ない単一のテーブル、または列は少ないが行が多い複数のテーブル？

例：ユーザーは自分の壁またはグループに更新を投稿できます。

私が考えることができる2つのデータベース設計は次のとおりです。

デザイン1

UserPosts

• id
• ユーザーID
• 役職
• 日付時刻

UserGroupPost：

• id
• groupId
• ユーザーID
• 役職
• 日付時刻

潜在的な問題：結合が必要になる可能性があり、（将来的には）クエリが遅くなる可能性があります。

デザイン2

投稿：

• id
• ユーザーID
• groupId
• 役職
• datetime（ユーザーが壁に投稿した場合、groupidはnullになります）

潜在的な問題：大きなデータセットをループすると、（長い）時間がかかる場合があります。

データが増加した場合、どのようにしてパフォーマンスを向上させることができますか？他に（より良い）方法はありますか？

ここでの私の傾向は、常にデザインオプション1、または少なくともそれらの線に沿ったものです。今後のクエリでテーブルを結合する必要性を排除しようとすることについてあまり心配しないでください。正規化されたデータベースは、リレーショナルデータベースである便利なクエリで結合を使用します。

また、ウェブサイトのuserPostsテーブルとuserGroupPostsテーブルに必ず参加する必要があるのはなぜですか。それらは個別に表示されませんか？これらのテーブルを結合する唯一の理由は、投稿を検索するときかもしれませんが、そのための効率的なクエリを書くことはそれほど難しくありません。それとは別に、分析の目的でテーブルをクエリしたくなるかもしれませんが、それはこのデータベースの主な目的ではありません。

デザイン2は、少なくとも、非常にビジーなテーブルになることを意味します。

ただし、それぞれのプロトタイプを作成して、いくつかのテストを実行するのが最善の方法です。各デザインオプションのプロトタイプを作成し、ダミーデータを使用してさまざまな操作でパフォーマンスベンチマークを実行します。

私にとって、あなたの現在の構造によると、デザイン2の方が優れています。パーティショニング、最適化されたクエリ、データベース/テーブルを作成する構造化された方法を実装して、実行時間を短縮できます。ただし、一部のケースでは正規化の方が効果的ですが、完全にデータベース設計アーキテクチャに依存しています。