複数のMySQLテーブルと1つの大きなテーブルのどちらがより効率的ですか？

MySQLデータベースにさまざまなユーザーの詳細を保存します。もともとは、さまざまなテーブルで設定されていたため、データがUserIdとリンクされ、必要に応じてデータを表示および操作するための複雑な呼び出しを介して出力されていました。新しいシステムをセットアップする場合、これらのすべてのテーブルを関連するコンテンツの1つの大きなテーブルに結合することはほぼ理にかなっています。

• これは助けになりますか、それとも妨げになりますか？
• 呼び出し、更新、検索/操作の速度に関する考慮事項？

これが私のテーブル構造の例です：

• users-ユーザーID、ユーザー名、電子メール、暗号化パスワード、登録日、IP
• user_details-Cookieデータ、名前、住所、連絡先の詳細、所属、人口統計データ
• user_activity-投稿、最後のオンライン、最後の閲覧
• user_settings-プロファイル表示設定
• user_interests-ターゲット設定可能な変数の広告
• user_levels-アクセス権
• user_stats-ヒット、タリー

編集：私はこれまですべての回答に賛成してきましたが、それらにはすべて、基本的に私の質問に答える要素があります。

ほとんどのテーブルには1：1の関係があり、これが非正規化の主な理由でした。

これらのセルの大部分が空のままである可​​能性が高いときに、テーブルが100以上の列にまたがっている場合に問題が発生しますか？

複数のテーブルは、次の方法/ケースで役立ちます。

（a）さまざまな人々がさまざまなテーブルを含むアプリケーションを開発しようとしている場合、それらを分割することは理にかなっています。

（b）データ収集のさまざまな部分について、さまざまな人々にさまざまな種類の権限を与えたい場合は、それらを分割する方が便利な場合があります。（もちろん、ビューの定義とビューへの許可の付与を適切に確認できます）。

（c）特に開発中にデータを別の場所に移動する場合は、テーブルを使用してファイルサイズを小さくすることは理にかなっています。

（d）単一のエンティティの特定のデータコレクションでアプリケーションを開発する場合、フットプリントが小さいと快適になります。

（e）これは可能性です。単一の値のデータとして考えていたものが、将来的には実際には複数の値になる可能性があります。たとえば、与信限度は現在のところ単一の値フィールドです。しかし、明日、値を（開始日、終了日、クレジット値）に変更することを決定する場合があります。分割テーブルが便利になるかもしれません。

私の投票は、データが適切に分割された複数のテーブルに対するものです。

幸運を。

テーブルを結合することを非正規化と呼びます。

JOINメンテナンス地獄を作成する代わりに、いくつかのクエリ（多数のsを作成する）を高速に実行すると役立つ場合とそうでない場合があります。

MySQLJOINメソッドのみを使用できますNESTED LOOPS。

これは、駆動テーブル内の各レコードについて、駆動MySQLされるテーブル内の一致するレコードをループで検索することを意味します。

レコードの検索は非常にコストのかかる操作であり、純粋なレコードのスキャンよりも数十倍かかる場合があります。

すべてのレコードを1つのテーブルに移動すると、この操作を取り除くのに役立ちますが、テーブル自体が大きくなり、テーブルのスキャンに時間がかかります。

他のテーブルに多数のレコードがある場合、テーブルスキャンを増やすと、レコードが順番にスキャンされるメリットを過大評価する可能性があります。

一方、メンテナンス地獄は保証されています。

それらはすべて1対1の関係ですか？つまり、ユーザーが異なるユーザーレベルに属している場合や、ユーザーの興味がユーザーの興味テーブルの複数のレコードとして表されている場合、それらのテーブルをマージすることはすぐには問題外です。

正規化に関するこれまでの回答については、データベースの正規化ルールはパフォーマンスを完全に無視しており、きちんとしたデータベースの設計とは何かを検討しているにすぎません。それはたいてい達成したいことですが、パフォーマンスを追求して積極的に非正規化することが理にかなっている場合があります。

全体として、問題はテーブルにあるフィールドの数と、それらがアクセスされる頻度にあると思います。ユーザーのアクティビティがあまり面白くないことが多い場合は、パフォーマンスとメンテナンスの理由から、常に同じレコードに記録するのは面倒なことかもしれません。設定などの一部のデータが非常に頻繁にアクセスされるが、単にフィールドが多すぎる場合、テーブルをマージすることも不便かもしれません。パフォーマンスの向上のみに関心がある場合は、設定を個別に維持し、独自のセッション変数に保存して、データベースに頻繁にクエリを実行する必要がないようにするなど、他のアプローチを検討できます。

くださいすべてのこれらのテーブルのは、持っている1-to-1関係？たとえば、各ユーザー行には、user_statsまたはに対応する行が1つだけありuser_levelsますか？その場合、それらを1つのテーブルに結合することは理にかなっています。ただし、関係がない 場合は、1 to 1それらを組み合わせる（非正規化する）ことはおそらく意味がありません。

数十万または数百万のユーザーレコードがない限り、それらを別々のテーブルと1つのテーブルに置いても、パフォーマンスへの影響はほとんどありません。あなたが得る唯一の真の利益は、それらを組み合わせることによってクエリを単純化することからです。

ETA：

列が多すぎることを懸念する場合は、通常一緒に使用するものを考え、それらを組み合わせて、残りを別のテーブル（または必要に応じていくつかの別のテーブル）に残します。

データの使用方法を見ると、クエリの80％がそのデータの20％を使用しており、残りの80％のデータはたまにしか使用されていないことがわかると思います。頻繁に使用する20％を1つのテーブルにまとめ、あまり使用しない80％は別のテーブルに残してください。そうすれば、妥協点が見つかるでしょう。

1つの大きなテーブルを作成すると、リレーショナルデータベースのプリンシパルに反することになります。それらすべてを1つのテーブルにまとめることはしません。繰り返しデータの複数のインスタンスを取得します。たとえば、ユーザーに3つの関心がある場合、3つの行があり、3つの異なる関心を格納するためだけに同じユーザーデータが含まれます。間違いなく、複数の「正規化された」テーブルアプローチを採用してください。データベースの正規化については、この Wikiページを参照してください。

編集： あなたがあなたの質問を更新したので、私は私の答えを更新しました...それ以来、私の最初の答えにさらに同意します...

これらのセルの大部分は空のままである可​​能性があります

たとえば、ユーザーが関心を持っていなかった場合、正規化すると、そのユーザーの関心テーブルに行が含まれなくなります。1つの大規模なテーブルにすべてがある場合、NULLのみを含む列（および明らかにそれらの多く）があります。

私は、大量のテーブルが存在するテレフォニー会社で働いていました。データを取得するには、多くの結合が必要になる可能性があります。これらのテーブルからの読み取りのパフォーマンスが重要である場合、作成されたプロシージャは、レポートが指す結合、計算などを必要としないフラットテーブル（つまり、非正規化テーブル）を生成できます。これらは、SQLサーバーエージェントと組み合わせて使用​​され、一定の間隔でジョブを実行します（つまり、一部の統計の週次ビューが週に1回実行されるなど）。

誰もが持つ基本的なユーザー情報を含むユーザーテーブルを用意し、基本的にユーザーIDに関連付けられた任意のキーと値のペアにできる「user_meta」テーブルを追加して、Wordpressが行う同じアプローチを使用しないのはなぜですか。したがって、ユーザーのすべてのメタ情報を検索する必要がある場合は、それをクエリに追加できます。また、ログインなどの必要がない場合は、常に追加のクエリを追加する必要はありません。このアプローチの利点は、Twitterハンドルや個々の関心を保存するなど、ユーザーに新しい機能を追加するためにテーブルを開いたままにすることです。また、すべてのメタデータをルール化する1つのテーブルがあり、50ではなく1つの関連付けに制限するため、関連付けられたIDの迷路に対処する必要はありません。

Wordpressは特にプラグインを介して機能を追加できるようにするためにこれを行うので、プロジェクトをよりスケーラブルにでき、新しい機能を追加する必要がある場合に完全なデータベースのオーバーホールを必要としません。

これは、「状況次第」の状況の1つだと思います。複数のテーブルを用意する方がクリーンであり、おそらく理論的には優れています。ただし、1人のユーザーに関する情報を取得するために6〜7個のテーブルを結合する必要がある場合、そのアプローチを再考する必要があるかもしれません。

他のテーブルが実際に何を意味するかによると思います。user_detailsには、1つ以上の/ユーザーなどが含まれていますか？正規化のどのレベルがニーズに最も適しているかは、要件によって異なります。

インデックスが優れているテーブルが1つある場合は、おそらくより高速になります。しかし、その一方で、おそらくメンテナンスがより困難です。

それはおそらくユーザーとの1対1の関係なので、私にはUser_Detailsをスキップできるように見えます。しかし、残りはおそらくユーザーあたりの行の多くですか？