データベースの効率-ユーザーごとのテーブルとユーザーのテーブル
ユーザーがいるウェブサイトの場合。任意の量を作成する能力を持つ各ユーザーは、それを「投稿」と呼びます。
効率的には、すべての投稿に対して1つのテーブルを作成し、投稿ごとに投稿を作成したユーザーのユーザーIDを保存することをお勧めします-OR異なる個別の作成- テーブルユーザーごとに、そのユーザーが作成した投稿だけを配置しますか？
データベースにデータを追加してもデータベースのレイアウトは変更されないため、ユーザーデータは確実に1つのテーブルに含まれている必要があります。
また：
複数のテーブルがあるということは、クエリを動的に作成する必要があることを意味します。
1つのテーブルのキャッシュされたクエリプランは、他のテーブルには使用されません。
1つのテーブルに多くのデータがあることはパフォーマンスにあまり影響しませんが、多くのテーブルがあることは影響します。
クエリを高速化するためにテーブルにインデックスを追加する場合は、単一のテーブルで行う方がはるかに簡単です。
特定の質問に答えるには、クエリの効率の観点から、小さなテーブルを使用する方が常に優れているため、ユーザーごとのテーブルが最も効率的である可能性があります。
ただし、投稿とユーザーがたくさんない限り、これは問題にならない可能性があります。数百万の行がある場合でも、適切に配置されたインデックスを使用すると、優れたパフォーマンスが得られます。
ソリューションが非常に複雑になるため、ユーザーごとのテーブル戦略には強くお勧めします。たとえば、1年以内に主題に投稿したユーザーを見つける必要がある場合、どのようにクエリを実行しますか？
必要なときに最適化します。何かが遅くなると思う/恐れているからではありません。 （最適化する必要がある場合でも、ユーザーごとのテーブルよりも簡単なオプションがあります）
テーブルの数が異なるスキーマは、一般的に悪いものです。投稿には1つのテーブルを使用してください。
単一のuserテーブルと単一のpostテーブルを持つという最初の提案は、採用する標準的なアプローチです。
現時点では、投稿はサイトの唯一のユーザー固有の機能である可能性がありますが、メッセージや設定などを持つユーザーをサポートするために、将来的に成長する必要があるかもしれないと想像してください。ユーザーごとの個別のアプローチは爆発につながります作成する必要のあるテーブルの数。
パフォーマンスが懸念される場合は、データベースインデックスについて学ぶ必要があります。インデックスはSQL標準の一部ではありませんが、ほぼすべてのデータベースがパフォーマンスの向上に役立つようにインデックスをサポートしています。
検索のパフォーマンスを向上させるために、すべてのユーザーの投稿に対して単一のテーブルを作成してから、このテーブルにインデックスを追加することをお勧めします。たとえば、user列にインデックスを追加して、特定のユーザーのすべての投稿をすばやく見つけることができます。アプリケーションの要件に応じて、他のインデックスの追加を検討することもできます。