正規化はどこまで行けばいいですか？
データベースに適切な量のデータがあります。私は整形式のテーブルとそれらの間の良好な関係を持っていますが、私のデータにはある程度の冗長性があります。しかし、正規化はどこまで行けばよいのでしょうか。正規化しすぎるとパフォーマンスが低下しますか？
あなたはあなたができる限り行くべきであり、それ以上行くべきではありません。もちろん。 〜問題は、これがちょっとした芸術であり、これが純粋な科学ではない理由です
私たちの主な製品は分析およびレポートシステムであり、そのため、かなりの数の詳細レコードがあります。最初は、いくつかの子レコードの共通IDに多くの結合を使用して設計しましたが、いくつかのフィールドを非正規化すると、結合の多くを切り捨てることができ、多くのパフォーマンスの頭痛の種を取り除くことができることがわかりました。
ただし、1）「正規化された」設計を作成した、2）使用を開始した、3）数十のテーブルにわたって数億行を実行した後の実際のパフォーマンスのプロファイルを作成したことだけがわかった。
最後の話は、私たちがprofiledになるまで、何がうまくいくのかがはっきりとわからなかったことです。より簡単に更新できるように正規化するという考えが気に入りましたが、最終的には実際のパフォーマンスが決定的な要因でした。それはあなたへの私のアドバイスです：プロフィール、プロフィール、プロフィール。
正規化が目標となるのは、データモデルがそれを保証するのに十分にサポートされている場合のみです。これは、成長、管理、保守性を可能にするためのガイドとなることを目的としています。正規化に関する本もその作者も、データベースやそのアプリケーションを構築または維持するつもりはないことに注意してください。
そして、はい、正規化が多すぎるとパフォーマンスに影響が出る可能性があります。これは、別のテーブルにプルされたときにステータスインジケーターテーブルなどを取得するための、より深いテーブルトラバーサルになります。これは通常、更新速度（ステータステキストを "Good"から "GOOD"に変更するなど）または保守性の面で無効になっていると言う人もいます。
Chris Date の最新の本のいくつかにある次の付録を読むことをお勧めします。
正規化は万能薬とはほど遠いです。目標が何であるか、それがどれだけうまく対処できるかを検討することで簡単に確認できます...
このセクションのコメントを、いかなる種類の攻撃としても見たくないことを明確にしなければなりません。完全に正規化されたデザインに満たないものは禁忌であると強く信じています...
明示的に追加された非正規化、追加された集計値、または詳細コピーにコピーされたマスターテーブルの一部のフィールドを確認することも同様に重要だと思います。
議論は主にいくつかのパフォーマンスの議論です。
強制する場合、これらのフィールドはトリガーによって更新され、一貫性を保つのはデータベースに任されています。
@jcolebrandに完全に同意します。アプリケーションのモデルを設計するときは、できる限りすべてを正規化する必要があります。ただし、次に、モデル上に構築されたクエリ、特に頻繁に実行されるクエリをプロファイルする必要があります。
私自身の経験：2つの結合に到達する（つまり、3つのテーブルが結合される）属性は、ほとんどがパフォーマンスを独占します。最悪の場合、オンライントランザクションで使用されます。私は属性を非正規化しているので、結合が1つだけ必要であり、クエリに合わせてアプリを調整して属性を更新するようにプログラマーに依頼しました。今でははるかにうまくいきます...
つまり、正規化とパフォーマンスのバランスをとる必要があります。