Webアプリケーションのクライアントごとに新しいテーブルを作成することは良い考えですか？

これは半仮説であり、大規模なデータベーステーブルを処理した経験がないため、何らかの理由でこれが恐ろしいかどうかはわかりません。状況について：

20,000のクライアントがあり、各クライアントがテーブルに1000以上のエントリを持つWebベースのアプリケーションを想像してみてください。これは2,000万行であり、複雑なクエリの速度を確実に低下させる可能性があります。

このような場合、クライアントごとにデータベースに新しいテーブルを作成する方が理にかなっていますか？2万（またはそれ以上）のテーブルがある場合、データベースはどのように反応しますか？

一般的に言えば、いいえ、顧客ごとにテーブル（ここでは実際にはデータベースを意味する）を持つことは意味がありません。データベーステーブルの場合、2,000万行は比較的小さいです。データベースが適切に調整（インデックス付け）され、クエリが正しくまとめられている限り、それに対するクエリ速度は問題になりません。それらを分離することから得られると考えられるどんな利点でも、20,000の個別データベースを管理するという追加の複雑さによって相殺されます。たとえば、テーブル構造を変更したい場合はどうなりますか？あなたは今それを20,000回行う必要があります！

さらに悪いことに、最終的にデータベースのサイズが問題になっていることがわかった場合、後でいつでもそれらを別々のデータベースに分割することができます。

悪い考えのように聞こえます。

このようなエキゾチックな構造でデータベースの裏をかこうとしないでください。データベースエンジンは、大きなデータセットを処理するために多くの最適化を行って設計されています。たとえば、あなたが説明しているものは、手動でインデックスを実装する試みに非常に近い音です。DBエンジンが提供するインデックスを使用するだけで、自分で実行できる可能性があるよりもはるかに優れた方法で実装され、それほど多くのメンテナンスを必要としません。

また、一般的な経験則として。アプリケーションの通常の使用中にデータベース構造（テーブル、フィールド）の操作または作成を必要とする方法でデータベースを構築しないことをお勧めします。これにより、パフォーマンスの最適化が困難になり、セキュリティホールを作成する可能性のある日常的なタスクを実行するために、ユーザーに多くの権限を与えることを余儀なくされます。

これが私がいつも人々にこの質問をするときに読むことを勧める記事です：

http://datacharmer.blogspot.com/2009/03/normalization-and-smoking.html

単一のテーブルが問題になるはずがないので、まだ存在しない問題は作成しないでください。パフォーマンスを向上させるためにできることはたくさんあります。IOに役立つように、clientIDまたは日付フィールドに基づいて単一のテーブルを複数のファイルに分割できます。データベースは、サイトが必要とするすべてのクエリに対して、20,000の異なるSQLステートメントを追跡、最適化、およびキャッシュする必要はありません。clientidでインデックスを作成できます。20Kのクライアントは、多くのハードウェアの代金を支払うことができます。

このタイプのテーブルでは、NoSQLタイプのdbを使用できます。

20Kのクライアントでは、データベースが最も弱いリンクではない可能性があります。なぜこれほど複雑なものを導入するのでしょうか。

それは本当に悪いアプローチです。

テーブルを垂直に分割します。1つは奇数のユーザーID用で、もう1つは偶数用の2つのデータベースサーバーで適切に機能します（データはユーザー間では関係ありません）。

データをuser_idでソートし、それが不可能な場合は、大量のRAMまたはSSDディスクを取得します。