DB (MySQL など) のスキーマを設計する場合、テーブルを完全に正規化するかどうかという問題が生じます。
一方では結合 (および外部キー制約など) が非常に遅く、他方では冗長なデータと不整合の可能性があります。
ここで「最後に最適化する」のは正しいアプローチですか? つまり、標準化された DB を作成し、最適な速度向上を達成するために非正規化できるものを確認します。
このアプローチに関する私の懸念は、十分に高速ではない可能性のある DB 設計に落ち着くということですが、その段階で (既存のデータをサポートしながら) スキーマをリファクタリングすることは非常に苦痛です。これが、「適切な」RDBMS プラクティスについて学んだことを一時的にすべて忘れて、「フラット テーブル」アプローチを一度だけ試してみたくなる理由です。
この DB が挿入を多用するという事実は、決定に影響を与えるべきでしょうか?
哲学的な答え: 次善の (リレーショナル) データベースには、挿入、更新、および削除の異常が蔓延しています。これらはすべてデータの不整合につながり、結果としてデータ品質が低下します。データの正確性を信頼できない場合、それは何の役に立つでしょうか? 自問してみてください: 正しい答えを遅くしたいですか、それとも間違った答えを早くしたいですか?
実際問題として、すぐに取得する前に取得してください。私たち人間は、どこでボトルネックが発生するかを予測するのが非常に苦手です。データベースを優れたものにし、適切な期間にわたってパフォーマンスを測定してから、高速化する必要があるかどうかを判断してください。非正規化して精度を犠牲にする前に、他の手法を試してください。より高速なサーバー、接続、db ドライバーなどを入手できますか? ストアド プロシージャによって速度が向上する可能性はありますか? インデックスとその FILL FACTOR はどうですか? これらおよびその他のパフォーマンスおよびチューニング手法でうまくいかない場合にのみ、非正規化を検討してください。次に、パフォーマンスを測定して、「支払った」速度が向上したことを確認します。悲観化ではなく、最適化を実行していることを確認してください。
[編集]
Q: 最適化を最後に行う場合、スキーマの変更後にデータを移行する合理的な方法を教えてください。たとえば、ルックアップ テーブルを削除することにした場合、既存のデータベースをこの新しい設計に移行するにはどうすればよいですか?
A: わかりました。
しかし...より堅牢なアプローチを検討してください：
今すぐ、完全に正規化されたテーブルにいくつかのビューを作成してください。これらのビュー (仮想テーブル、データの「ウィンドウ」... このトピックについて詳しく知りたい場合は私に尋ねてください) には、上記の手順 3 と同じ定義クエリがあります。アプリケーションまたは DB 層のロジックを作成するときは、ビューを使用します (少なくとも読み取りアクセス用です。更新可能なビューは... 興味深いものです)。次に、後で非正規化する場合は、上記のように新しいテーブルを作成し、ビューを削除して、新しいベース テーブルの名前を変更します。アプリケーション/DB レイヤーは違いを認識しません。
実際にはこれにはさらに多くのことがありますが、これで始めることができます。
データベースの使用パターン (挿入が多い vs. レポートが多い) は、確実に正規化に影響します。さらに、正規化されたテーブルで大幅な速度低下が見られる場合は、インデックス作成などを確認することをお勧めします。どのバージョンの MySQL を使用していますか?
一般に、挿入が多いデータベースは、レポートが多いデータベースよりも正規化する必要があります。しかし、もちろんYMMV...
通常の設計が出発点です。速くする必要はないかもしれないので、最初に正しく理解してください。
時間のかかる結合に関する懸念は、多くの場合、貧弱な設計の経験に基づいています。設計がより正常になるにつれて、設計内のテーブルの数は通常増加しますが、各テーブル内の列と行の数は減少し、結合の数が減少するにつれて設計内の共用体の数が増加し、指標がより有用になります。言い換えれば、良いことが起こります。
ノーマライゼーションは、最終的に正常な設計になるための 1 つの方法にすぎません...
「結合 (および外部キー制約など) が非常に遅い」という考えはどこから得ましたか? これは非常にあいまいなステートメントであり、通常、IMO ではパフォーマンスの問題はありません。
運用システムで非正規化が必要になることはめったにありません。私がデータ モデルを作成したあるシステムには、560 前後のテーブルがあり (当時、オーストラリアで構築された最大の J2EE システムでした)、非正規化されたデータは 4 つしかありませんでした。そのうちの 2 つは、複雑な検索画面を容易にするために設計された非正規化検索テーブル (1 つは具体化されたビュー) であり、他の 2 つは特定のパフォーマンス要件に応じて追加されました。
非正規化されたデータでデータベースを時期尚早に最適化しないでください。これは、進行中のデータ整合性の問題のレシピです。また、常にデータベース トリガーを使用して、非正規化されたデータを管理します。アプリケーションに依存しないでください。
最後に、レポートのパフォーマンスを向上させる必要がある場合は、データ マートまたはレポート用の別の非正規化構造を構築することを検討してください。大量のデータに対して計算された集計のリアルタイム ビューの要件を組み合わせたレポートはまれであり、少数の事業部門でのみ発生する傾向があります。これを行うことができるシステムは、構築するのが非常に面倒で、したがって高価になる傾向があります。
ほとんどの場合、最新のデータを本当に必要とする少数のレポートしかなく、ほとんどの場合、To Do リストや少量のデータで機能する例外レポートなどの運用レポートになります。それ以外のものはすべてデータ マートにプッシュできますが、これにはおそらく夜間の更新で十分です。
挿入が多いデータベースでは、間違いなく正規化されたテーブルから始めます。クエリのパフォーマンスに問題がある場合は、まずクエリを最適化し、有用なインデックスを追加してみます。
これで問題が解決しない場合にのみ、非正規化テーブルを試してください。挿入の速度が低下している可能性があるため、非正規化の前後に挿入とクエリの両方を必ずベンチマークしてください。
ここで「最後に最適化する」のは正しいアプローチですか? つまり、正規の正規化された DB を作成し、最適な速度向上を達成するために何を非正規化できるかを確認します。
そうです。私はよく考えずに「フラットテーブル」を容認するために、構造の悪い DB に何度も対処しなければなりませんでした。
実際、挿入は通常、完全に正規化された DB で適切に動作するため、挿入が多い場合は問題になりません。
この問題に対する一般的な設計アプローチは、まずデータベースを第 3 正規形に完全に正規化してから、パフォーマンスとアクセスのしやすさに応じて非正規化することです。このアプローチは、デフォルトで正規化しないのではなく、設計によって特定の決定を下しているため、最も安全な傾向があります。
「必要に応じて」は、経験が必要なトリッキーな部分です。正規化はかなり「暗記」の手順であり、どこで非正規化するかはあまり正確ではなく、アプリケーションの使用法とビジネス ルールに依存し、結果としてアプリケーションごとに異なることを知っていれば、教えることができます。すべての非正規化の決定は、仲間の専門家にとって弁護できるものでなければなりません。
たとえば、1 対多の関係がある場合、A から BI に出荷する場合、ほとんどの場合、これは正規化されたままになりますが、ビジネスで A ごとに B が 2 回しか発生しないことがわかっている場合、これが変わる可能性はほとんどありません。 B レコードのデータは限られています。そして、彼らは通常、A レコードで B データをプルバックします。私は、B フィールドの 2 つのオカレンスで A レコードを拡張する可能性が最も高いでしょう。もちろん、合格しているほとんどの DBA は、すぐにこれを設計上の問題の可能性としてフラグを立てます。
このことから、非正規化は例外であることは明らかです。実稼働データベースでは、その大部分 (95% 以上) が第 3 正規形であり、非正規化された構造がほんの一握りであると予想されます。
私がデータベースについて読んだほとんどの本には、データベース設計の非正規化と同じことである最適化に関するトピックが含まれているため、本でデータベースを作成することについてあなたが何を意味するのかわかりません。
これはバランスをとる行為なので、時期尚早に最適化しないでください。その理由は、非正規化されたデータベース設計は扱いにくくなる傾向があるためです。いくつかのメトリックが必要になるため、非正規化しないかどうかを決定するために、データベースでストレス テストを行います。
したがって、保守性のために正規化しますが、最適化のために非正規化します。