5-1 正規化の功罪

正規化には副作用がある

正規化とSQL（検索）

第3正規化まで済んだテーブル群があるとする

https://scrapbox.io/files/68776738e637375f80ae031e.jpg

内部結合を使うケース

〇〇さんが今勤めている会社名と部署名を知りたいとき、上記3つのテーブルを結合する必要がある

正規化されたテーブルは単独のテーブルでは、欲しい情報を取得できないことが多い

外部結合を使うケース

会社ごとの社員数を集計したいとき、上記3つのテーブルを結合する必要がある

SQLにおける結合は、非常にコストが高い操作

結合するテーブル数、テーブルのレコード数が増えるほど、パフォーマンスが悪化する

非正規化による解決

上記のテーブル結合を回避して、パフォーマンス悪化を防ぐ策がある

それは正規化をしないこと

第2正規化以前のテーブル

https://scrapbox.io/files/6877672f538bde92f52923aa.jpg

正規化とSQL（更新）

更新処理のおいては、正規化と非正規化では、正規化に軍配が上がる

例えば、上記2つのテーブル（第3正規化済みと第2正規化以前）があったとする

会社名が変わることになった場合、第2正規化以前だと社員テーブルの対象の会社名の全レコードを更新する必要がある

第3正規化済みであれば会社テーブルの1レコードだけを更新すれば良い

正規化と非正規化、どちらが正解なのか？

人によって意見が分かれる

それだけ正規化と検索SQLのパフォーマンスは、トレードオフの関係にある

パフォーマンスと取るか、データの整合性を取るか

https://scrapbox.io/files/68776924c5030cc9dc188799.jpg

著者の立場は、原則として非正規化は許さない

正規化の設計を諦めて良いのは、パフォーマンス向上のためのその他全ての戦略が要件を満たさないとき