新しいアプリ用に mySQL Workbench を使用してデータベース構造を作成しています。データのリストを作成するために必要な結合の数は、多対多の関係が増加するにつれて大幅に増加しています。
アプリケーションは非常に読み取り負荷が高く、テーブルごとに数十万行あります。
質問：
必要に応じてテーブルをマージして、結合を減らすのは本当に悪いことですか?
水平パーティショニングを検討する必要がありますか? (テーブルのマージと併用)
多対多の関係を処理するために、ピボット テーブルよりも優れた方法はありますか?
すべてのデータをシリアル化されたテキスト列に格納する代わりに、データベースではなくアプリケーションで並べ替えを行うことについて説明しましたが、データベースが大量にキャッシュされるにもかかわらず、これは非常に悪い考えのように思えます。どう思いますか？
データベースの正規化された形式を使用します。ほとんどのタスクでは、3 つまたは 4 つ以上の Join は必要なく、最も一般的な Join のビューを作成することもできます。非正規化では、1 つのプロパティを変更するときに、常に複数の場所/テーブルのフィールドを更新することを考える必要があり、利点よりも多くの問題が確実に発生します。
レポートのパフォーマンスが心配な場合でも、時間指定されたバッチでデータを個別のテーブルに抽出して、レポート クエリに必要なパフォーマンスを得ることができます。クエリを簡素化する場合は、ビューを使用できます。
逆の順序で:
忘れてください。データベースを使用します。「アプリケーションで作成する」と言う人々は、多くの場合、データベースの作成に費やされる作業量について無知です。
正確な必要性に依存します。
正確な必要性に依存します。OLTP (トランザクション処理) - 第 5 正規形に進みます。OLAP (分析処理) - 適切なスター ダイアグラムを使用し、非正規化して最適なパフォーマンスを実現します。混合 - 忘れてください。理論が異なるため、大規模なインストールでは機能しません...ただし、データベースを OLTP にしてから、特別な OLAP キューブ データベース (mySQL にはありません) を使用する場合を除きます。
データベースは、多数の結合を処理するように設計されています。この機能を使用すると、データベース内のさまざまな種類のデータ操作がはるかに簡単になります。それ以外の場合は、フラット ファイルを使用しないでください。
外部キーのインデックスを作成し (外部キーを設定しましたよね?)、クエリに適切な where 句を含めると、10 ～ 15 個の結合がデータベースで簡単に処理されるはずです。特に行が少ない場合。数百万行のテーブルに多数の結合を含むクエリがあり、正常に実行されます。
通常、データを非正規化するよりも分割する方が適切です。
非正規化に関する限り、非正規化されたデータを親テーブルと同期させるための戦略を策定しない限り、非正規化を行わないでください。
本当に多くのテーブルが必要なのか、それとも設計が悪いのかについては、テーブルの構造を確認するしかありません。
いつものように、それはアプリケーションによって異なりますが、一般に、あまりにも多くの非正規化が戻ってきて後で苦しむ可能性があります. データベースが適切に正規化されているということは、後で必要になる可能性のあるほとんどの方法でデータをクエリできることを意味します。
シリアル化されたテキスト列にすべてのデータを貼り付け、クライアントが特定の属性を持つすべての行を示すレポートを要求した場合、このデータを取得するために一連の文字列操作を行う必要があります。
クエリの結合が多すぎることが心配な場合は、特定のデータ セットをビューとして公開することを検討できます...
結合が原因でパフォーマンスが低下しているという明確な証拠がない限り、正規化を維持してください。そうしないと、他の人が言ったように、複数の更新について心配する必要があります。
特に、データベースが大量にキャッシュされている場合、おっしゃるように、DBMS がこの種の処理を実行する速度に驚かれることでしょう。
特別なパフォーマンスの最適化を必要とする膨大な量のデータを扱うモンスター アプリケーションでない限り、開発、テスト、およびその後のメンテナンス作業を抑えることがはるかに重要になることがわかります。
ジョインは良好ですが、通常は悪くありません。データをあるべき場所に保持できるため、最大限の柔軟性が得られます。
何度も言われているように、時期尚早の最適化は通常、良くも悪くも良くありません。