本記事の目的

正規化のデメリットを理解し、メリットとデメリットを踏まえて、どのようにトレードオフしていくかについての方針を考えること。

正規化のデメリット

正規化のメリットとしては、冗長性を排除し、データの整合性を向上させることでした。
詳しくは過去の記事に詳細を記載しています。

一方、正規化にはデメリットが大きく2点あります。
では、詳しくみていきましょう。

デメリット① パフォーマンスの低下

正規化を行うことで、データの検索時に複数のテーブルを結合する必要が生じ、検索クエリの実行速度が低下する可能性があります。
特に読み込みが多いシステムではパフォーマンスが悪化する場合があります。

例) ECサイトの商品データ検索
products テーブル：商品名や価格などの基本情報を管理

categories テーブル：商品カテゴリー情報を管理

SELECT p.id, p.name, p.price

FROM products p

INNER JOIN categories c ON p.category_id = c.id

WHERE c.name = '家電';

正規化された構造では、複数のテーブルを結合する必要があります。この結合操作（JOIN）はデータ量が増えるほど負荷が高くなり、クエリの応答時間が遅くなる原因になります。
上記例では商品数が数千、数万となると、JOIN処理が検索結果のボトルネックになり、ユーザーが待たされる時間が増えてしまいます。
一方、非正規化の場合、productsテーブルの中に全てのカラムが入っているため、以下のように結合操作を行わず検索することができます。

非正規化

products テーブル：商品名や価格などの基本情報を管理

SELECT id, name, price

FROM products

WHERE category_name = '家電';

と、このようになります。ただし、非正規化にはパフォーマンス面で別の問題もあります。
たとえば、カテゴリー名を変更する場合、該当する複数のレコードを更新しなければなりません。その結果、更新時のパフォーマンスに影響を与える可能性があります。

デメリット② クエリの複雑化

正規化が進むと、データを取得するためのクエリが複雑になります。複数のテーブルを結合する必要があるため、SQL文が長くなり、パフォーマンスに影響を与えるだけでなく、可読性も低下する可能性があります。

ただ、フレームワークが発達している近年では、正規化によるクエリの複雑化は、それほど大きなデメリットにはならないのでは？と個人的には思っています。
ORM（Object-Relational Mapping）の利用や、クエリビルダーの利用等によってデメリットは少し軽減されそうです。

終わり

これらのデメリットを踏まえた結果、基本的には第3正規化までは行いたいというのが個人的な感想です。
パフォーマンス以上に、保守性の向上、データの整合性の向上についてのメリットを大きく感じます。

非正規化を検討するタイミングとしては、

• 大規模データの高速検索が必要な場合
  
  
  
  • 例：Webサーバーログのリアルタイム解析
  
  
  
  


• リアルタイム性が重視される場合
  
  
  
  • 例：SNSのフィード表示等
  
  
  
  


• 高頻度な読み取りアクセス
  
  
  
  • 例：ECサイトの商品レコメンドシステム（商品情報・カテゴリー情報・在庫情報・購入履歴などの複数テーブルデータが必要）
  
  
  
  

といったところでしょうか。よっぽどデータ検索のスピードが求められない限り、基本的には正規化を行うのが良いのではないかと思います。ただし、実装途中でデータベースの構成変更は改修コストが非常に高くつくため、設計段階で慎重に考えることが重要ですね:)
後々、思わぬ手間や問題に直面することになるかもしれません。。（これに関しては設計全般に言えることではありますが）

それでは、ここまでお付き合いいただきありがとうございました！