skillup

技術ブログ

Database

正規化のデメリット

投稿日:2016年7月26日 更新日:

正規化のデメリット

正規化についていろいろ書いてきましたが、メリットもあればデメリットもあります。

メリットとしては

  • データの不整合が起きにくい
  • 更新時の処理が速い

ことなどがあげられるでしょう。

逆にデメリットもあります。

それは「結合により検索系のSQLが遅くなること」です。

このため、わざと非正規化したテーブル設計をすることもあるようです。

一般論としては正規化の次数があがるほど、検索スピードは落ちる傾向にあるようです。

ただそうはいっても「データの不整合は絶対に防がなくてはいけないこと」から非正規化は最終手段と考えられているようですね。

この点は私の経験からも一致しますね。基本的に今までテーブルは正規化されたものが基本で、非正規化されたものというのはほとんど見たことがありませんでしたので。

更新速度を上げるためのポイントはいろいろとありますが、その1つがサマリーデータの格納です。

例えば受注テーブルと受注詳細テーブルがあったとし、受注テーブルのカラムが受注ID,注文日、注文者、受注詳細テーブルには受注ID、明細連番、商品名があったとします。

ここで商品の売り上げや個数を知りたい場合、基本的に受注テーブルに受注詳細テーブルをJOINして持ってきます。

ここでスピードのボトルネックが発生するわけですが、もし商品数という情報を受注テーブルに加えると

  • 厳密な第三正規化ではなくなる
  • 更新時における問題が起こる可能性がある(データの不整合が起きる可能性がある)
  • 更新時の処理は逆に負荷がかかる

半面、

  • 検索処理が非常に簡単でハイパフォーマンス

になります。

その他、日ごとの注文情報を出したいなどといったときには受注詳細に受注日をいれておくことで日ごとの一覧情報を出したい、となったときにも高速な検索処理を行うことができるのです。

このように正規化を崩すことでパフォーマンスを上げることは可能です。ただ、機械的にできるものではないことやデータの不整合が起こる可能性があるため、慎重に行う必要があります。

またデータベースの変更はプログラムの変更に比べて厄介なことが多いため、後戻りが簡単にできません。この点でも慎重に行う必要があります。

本日のSQL

n日前やn時間前を出すときにSQLでシンプルにできる方法を知りませんでした(汗)

例えば今の時間の3日前は下記のように簡単にできます。

例えば1年以内の注文(order)を出したいといった場合、注文日(order_date)に下記のように検索条件を付けてあげればOKです。

[ MySQL ] n分前, n時間前, n日後の日付を取得する ( INTERVAL )

-Database
-

執筆者:


comment

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

関連記事

no image

MySQLのパフォーマンスチェックなどについて

常日頃MySQLをつかっているのですがパフォーマンスのチェックなどをあまりしていなかったため、これをチョクチョクしていこうかなあと思っております。 簡単に使えるツール(ただし5.1.4から)としては標 …

no image

EXISTSについて

今回はEXISTSについてです。 実務では伝票と明細との検索関連の処理で結構出てきます。 なお、達人に学ぶ~では論理学について少しふれており、この領域を本気で理解する場合は論理学を勉強する必要がありま …

no image

MySQLのLIMIT,OFFSETに関して&explainの見方など

自作のWEBアプリを作っていたところSELECT句が異常に遅いケースがありました。 発見までにかなり時間がかかったんですが、不可思議な現象としてはOFFSETが小さいときと大きいときで検索スピードが全 …

no image

アンチパターン データ分身の術+DBの不要な連携+バージョンアップ未テスト

今回のアンチパターンは主にデータ設計に関する部分。 Contents1 同一データの使用1.1 デメリット1.2 対策2 DBの不要な連携2.1 デメリット2.2 対策3 サーバーの移行やバージョンア …

no image

リレーションを含んだテーブルでの副問い合わせ

本日はSQLネタです。 下記のようなテーブル構成があったときとします。 注文ヘッダと注文詳細は(1:N)とします。 ここで、product_id=5を含んだ注文ヘッダーレコードを取り出したいとします。 …

アーカイブ