Facebookのグループと同じようなデザインのウェブサイトを作ろうとしています。ユーザーはグループに参加して、それらのグループ内に投稿できるようになります。ただし、グループと投稿に関してデータベーススキーマを作成するのに問題があります。これは、これまでの私のテーブルスキーマです。
Table 1: Users
Table 2: Groups
Table 3: Posts
投稿テーブルは、ユーザーがグループ内に投稿するたびに行を作成します。投稿テーブル内のその行には、投稿の対象となるグループの一意のIDと、投稿を作成したユーザーの一意のIDが含まれます。私の心配は、postテーブルが大きくなり、特にGroupsテーブルやUsersテーブルと比較して大きくなることです。
グループごとに多数の投稿（数百から数千）があることを考えると、グループごとに新しいテーブルを作成する必要がありますか？
この問題に関するありとあらゆる意見をいただければ幸いです。
一言で言えば、いいえ。複数のテーブルを作成しないでください。1つのグループテーブルが適切です。適切にインデックスを付けてください。数百または数千の投稿は、適切なインデックス付けで数百万の行を管理できるように設計されたデータベースにとって、実質的に何の意味もありません。テーブルの列はグループの所有権を識別する必要がありますが、別のテーブルに分割しないでください。
最悪の場合、ディスクスペースに収まるようにテーブルが手に負えないほど大きくなったときに、テーブルをパーティション分割することができます。ただし、それが大きくなる可能性は非常に小さいです。
数千万の投稿に関心がある場合、投稿が非常に大きい可能性がある場合、またはハードウェアが非常に限られている場合を除いて、グループIDにインデックスがある限り、単一のMySQLテーブルで問題ありません。
数百万以上の行について話していない限り、テーブルに正しくインデックスを付ける（両方のIDでインデックスを付ける）限り、問題はありません。
単純化した見方をすると、データ項目間に何らかの依存関係がある場合は、新しいテーブルを作成する必要があります。ここでより正確に調べることができます：http：//en.wiktionary.org/wiki/first_normal_form
ただし、テーブルが大きくなりすぎるたびに新しいテーブルを作成する必要があるとは記載されていません。それはデータベース管理者にとっては何かでしょう。あなたの例では、最新の投稿は5か月前に書かれた投稿よりも頻繁に読まれます。適切なインデックスを作成し、データ行の重複を避けるために、次のような構造を使用できます。
注）この図は次のように述べています。i）1人のユーザーが1つ以上のグループに投稿し、ii）1つのグループに1人以上のユーザーがいる、iii）1つの投稿がグループ内の1人以上のユーザーに表示されます。3つの関係はすべて1対多であり、ユーザーとグループ間のカーディナリティは多対多です。
さらに、投稿（時間の経過とともに大きくなる可能性が高いテーブル）を数年、数か月、さらには数週間に「グループ化/構造化」することができます。したがって、どの期間かを言うことができます。これにより、この時間係数を、別のテーブルではなく、投稿テーブルの日付フィールドにすることもできます。
