ユーザーがいるウェブサイトの場合。任意の量を作成する能力を持つ各ユーザーは、それを「投稿」と呼びます。
効率的には、すべての投稿に対して1つのテーブルを作成し、投稿ごとに投稿を作成したユーザーのユーザーIDを保存するか、ユーザーごとに異なるテーブルを作成して、作成した投稿だけを配置する方がよいでしょう。そのユーザーによって？
15626 次
6 に答える
45
データベースにデータを追加してもデータベースのレイアウトは変更されないため、ユーザーデータは確実に1つのテーブルに含まれている必要があります。
また：
複数のテーブルがあるということは、クエリを動的に作成する必要があることを意味します。
1つのテーブルのキャッシュされたクエリプランは、他のテーブルには使用されません。
1つのテーブルに多くのデータがあることはパフォーマンスにあまり影響しませんが、多くのテーブルがあることは影響します。
テーブルにインデックスを追加してクエリを高速化する場合は、単一のテーブルで行う方がはるかに簡単です。
于 2011-09-25T09:08:00.687 に答える
12
特定の質問に答えるには、クエリの効率の観点から、小さなテーブルを使用する方が常に優れているため、ユーザーごとのテーブルが最も効率的である可能性があります。
ただし、投稿やユーザーが多い場合を除いて、これは問題にならない可能性があります。何百万もの行がある場合でも、適切に配置されたインデックスを使用すると、優れたパフォーマンスが得られます。
ソリューションが非常に複雑になるため、ユーザーごとのテーブル戦略には反対することを強くお勧めします。たとえば、1年以内に特定のテーマに投稿したユーザーを見つける必要がある場合、どのようにクエリを実行しますか？
必要なときに最適化します。何かが遅くなると思う/恐れているからではありません。（最適化する必要がある場合でも、ユーザーごとのテーブルよりも簡単なオプションがあります）
于 2011-09-25T09:01:28.320 に答える
8
テーブルの数が変化するスキーマは、一般的に悪いものです。投稿には1つのテーブルを使用します。
于 2011-09-25T08:55:59.470 に答える
5
パフォーマンスが懸念される場合は、データベースインデックスについて学ぶ必要があります。インデックスはSQL標準の一部ではありませんが、ほぼすべてのデータベースがパフォーマンスの向上に役立つようにインデックスをサポートしています。
すべてのユーザーの投稿に対して単一のテーブルを作成してから、このテーブルにインデックスを追加して、検索のパフォーマンスを向上させることをお勧めします。たとえば、user列にインデックスを追加して、特定のユーザーのすべての投稿をすばやく見つけることができます。アプリケーションの要件に応じて、他のインデックスの追加を検討することもできます。
于 2011-09-25T09:00:53.957 に答える
4
user単一のpostテーブルを持つという最初の提案は、採用する標準的なアプローチです。
現時点では、投稿はサイトの唯一のユーザー固有の機能である可能性がありますが、メッセージや設定などを持つユーザーをサポートするために、将来的に成長する必要があるかもしれないと想像してください。作成する必要のあるテーブルの数。
于 2011-09-25T09:12:33.583 に答える
0
@guffaと@driisはどちらも「投稿」をユーザー間で共有する必要があると想定しているため、あなたの回答には似ていますが異なる問題があります。
私の特定の状況では、プライバシー上の理由から、分析のためであっても、他のユーザーと単一のユーザーデータポイントを共有することはできません。
mysqlまたはpostgresの使用を計画しており、チームが争っている3つのオプションは次のとおりです。
N個のスキーマと5つのテーブル-一部の開発者は、これがデータを完全に分離しておくための最善の方向であると感じています。長所-スキーマをフォルダー、テーブルをファイルと考えると、複雑さが軽減されます。ユーザーごとに1つのスキーマがあります短所-ほとんどのORMは、スキーマごとに接続プールを実行します
1つのスキーマとnx5テーブル-接続プールを可能にするが、問題をより複雑にするように見えるため、このような一部の開発者。長所-ORMでの接続プールが可能です短所-モデルがこのために設定されているORMを見つけることができません
1つのスキーマと5つのテーブル-キャッシュの恩恵を受けると考えているため、このような開発者もいます。
長所：ORMは、これが実行するように設計されているため、満足しています。短所：すべてのクエリにはユーザー名テーブルが必要です。
私は個人的に、キャンプ1：nスキーマに着陸します。私のリード開発者はキャンプ3に着陸します：1スキーマ5テーブル。
キャッシング：データが常に1：1の場合、各ユーザーが異なる情報を検索するため、使用するソリューションに関係なく、キャッシングがどのように役立つかわかりません。
何かご意見は？
于 2020-11-22T19:38:44.770 に答える