3

私はすでにこの質問を含むいくつかのフォーラムを見ましたが、それらは私が知りたいことの1つに答えていません。最初に私のトピックを説明します：

複数のユーザーの各ログがデータベースに入力されるシステムがあります（例：User1がログイン、User2がログイン、User1がユーザー管理を入力、User2がパスワードを変更したなど）。したがって、ユーザーあたり1日あたり100〜200のエントリを期待しています。現在、私は単一のテーブルでそれを行っており、それを表示するには、UserIDを使用してフィルターで除外する必要があります。

私の質問は、どちらがより効率的ですか？1つのテーブルを使用する必要がありますか、それともユーザーごとにテーブルを作成する必要がありますか？

単一のテーブルを使用すると、システムで数千のエントリをフィルタリングするのが困難になる可能性があるのではないかと心配しています。特にテーブルの更新に関して、複数のテーブルと1つのテーブルを使用していくつかの長所と短所を読みました。

また、どちらがより多くのスペースを節約できるか知りたいですか？複数のテーブルまたは単一のテーブル？

4

7 に答える 7

2

私はシングルテーブルで行きます。userId のインデックスを使用すると、ほとんど問題なく数百万行に簡単にスケーリングできるはずです。

ユーザーごとのテーブルの方が効率的かもしれませんが、一般的に設計が不十分です。ユーザーごとのテーブルの問題は、「昨日ユーザー管理にいたのは誰ですか?」などの他の種類の質問に答えるのが難しくなることです。または「何人の人がパスワードを変更しましたか?」

使用されるストレージ容量については、ユーザーごとのテーブルはおそらくもう少し多くのスペースを使用すると思いますが、2 つのオプションの違いは非常に小さいはずです。

于 2011-03-01T15:02:48.647 に答える
2

選択しているフィールドでインデックスを使用している限り、速度の問題は発生しません (ただし、インデックスは書き込みが遅くなるため、多すぎるのは良くありません)。数千のエントリを持つテーブルは、mySQL (または他のデータベース エンジン) にとっては何の意味もありません。

数千のテーブルを作成するオーバーヘッドはさらに悪化します。ユーザー テーブルのフィールドに変更を加えるとします。今では、数千のテーブルを変更する必要があります。

1 つのレコード @ work を定期的に検索するテーブルには約 150,000 行があり、検索するフィールドはインデックス化されているため、検索時間はわずか 1 秒未満です。

主キーを使用せずにこれらのレコードを選択する場合は、選択に使用するフィールドに次のようにインデックスを作成します。

CREATE INDEX my_column_name ON my_table(my_column_name);

最も基本的な形です。詳細については、こちらをご覧ください

于 2011-03-01T15:00:30.067 に答える
1

確かに一人テーブル。アプリケーションによって作成されたエンティティに対してテーブルを動的に作成しても、スケーリングされません。また、変数テーブル名を使用してクエリを作成する必要があるため、デバッグと保守が困難になります。フィルタリングに使用するユーザーIDにインデックスがある場合、データベースが何百万行も処理することは大したことではありません。

于 2011-03-01T15:01:49.493 に答える
1

その価値のあるデータベースは、汗をかくことなく、すべてのユーザー情報を含む単一のテーブルを処理します。単一のテーブルは間違いなく正しい方法です。

複数のテーブルを使用した場合、新しいユーザーが登録するたびに新しいテーブルを作成する必要があります。クエリを実行したユーザーごとに新しいステートメント オブジェクトを作成する必要があります。それは完全な混乱でしょう。

于 2011-03-01T15:02:35.580 に答える
1

私はたった1つのテーブルで行きます。ユーザーがシステムに追加されるたびに新しいテーブルを作成したくないのは確かです。あなたが言及した 1 日あたりのエントリの数は、実際にはそれほど多くのデータではありません。

また、クエリ時間を改善するために、テーブルの user 列にインデックスを作成します。

于 2011-03-01T14:59:43.850 に答える
0

私もシングルテーブルに行きます。異なるユーザー セットを持つ複数の顧客にサービスを提供する場合 (マルチ テナンシー)、複数のテーブルを使用することをお勧めします。それ以外の場合は、複数のテーブルを使用する場合は、次のリファクタリング ツールを参照してください: http://www.liquibase.org/。その場でスキーマの変更を行うことができます。

つまり、適切なインデックス作成を使用している場合、単一のテーブル ソリューションで十分に実行できると思います (そして、メンテナンスははるかに簡単になります)。

于 2011-03-01T15:07:34.317 に答える