正規化はどこまで行けばいいですか？

データベースにはかなりの量のデータがあります。整形式のテーブルと、データ間の冗長性を備えたテーブル間の良好な関係があります。しかし、正規化はどこまで行えばよいのでしょうか？正規化が多すぎるとパフォーマンス上の欠点がありますか？

できる限り遠くに行く必要があり、それ以上はありません。もちろん。〜問題は、これがちょっとした芸術である可能性があり、これが純粋な科学ではない理由です。

私たちの主な製品は分析とレポートのシステムです。そのため、かなりの数の詳細レコードがあります。当初は、いくつかの子レコードの共通IDで多数の結合を使用して設計していましたが、いくつかのフィールドを非正規化すると、結合の多くを削減でき、パフォーマンスの頭痛の種を取り除くことができることがわかりました。

しかし、1）「正規化された」設計を作成し、2）使用を開始し、3）数十のテーブルにわたって数億行の後に実際のパフォーマンスをプロファイリングしたため、私たちは知っていました。

最後の話は、プロファイルを作成するまでは、何がうまくいくかを確実に知ることができなかったということです。より簡単に更新できるように正規化するアイデアが好きでしたが、最終的には実際のパフォーマンスが決定的な要因でした。それが私のアドバイスです。プロフィール、プロフィール、プロフィール。

正規化は、データモデルが十分にサポートされている場合にのみ、目標です。成長、管理、保守性を実現するためのガイドとなることを目的としています。正規化に関する本も、その著者も、データベースまたはそのアプリケーションを構築または保守することを忘れないでください。

「正規化が多すぎる」というテーマについては、こちらをご覧ください。

そして、はい、あまりにも多くの正規化にパフォーマンスの影響がある可能性があります。これは、別のテーブルに引き出された状態インジケータテーブルのようなものを取得するために、より深いテーブルトラバーサルになります。これは通常、更新速度（「良い」から「良い」へのステータステキストの変更など）または保守性で否定されます。

Chris Dateの最近の本のいくつかにある次の付録を読むことをお勧めします。

ノーマライズの2つの歓声

正規化は万能薬とはほど遠いものです。目標とは何か、それらをどれだけうまく評価するかを考えると簡単にわかります。

このセクションでの私のコメントを、あらゆる種類の攻撃と見なされたくないことを明確にする必要があります。完全に正規化されたデザインよりも小さいものはすべて禁忌と強く信じられます...

明示的に追加された非正規化、追加された集計値、または詳細コピーにコピーされたマスターテーブルの一部のフィールドを確認することも同様に重要だと思います。

引数は主にパフォーマンスの引数です。

強制する場合、それらのフィールドはトリガーによって更新され、それらの一貫性を保つのはデータベース次第です。

@jcolebrandに完全に同意します。アプリケーションのモデルを設計するときは、できる限りすべてを正規化する必要があります。ただし、モデル上に構築されたクエリ、特に頻繁に実行されるクエリのプロファイルを作成する必要があります。

私自身の経験：到達するまでに2つの結合（つまり、3つのテーブルが結合されること）を必要とした属性は、ほとんどがパフォーマンスを浪費します。そして、事態を悪化させるために、オンライントランザクションで使用されます。属性を非正規化するため、結合が1つだけ必要になり、クエリと属性の更新のためにアプリを調整するようプログラマーに依頼しました。今でははるかに良く機能します...

つまり、正規化とパフォーマンスのバランスを取る必要があります。