差分
ナビゲーションに移動
検索に移動
ページの作成:「'''データベースの非正規化'''とは、データベースの教科書に載っている「データベースの正規化」とまったく逆のことを行う...」
'''データベースの非正規化'''とは、データベースの教科書に載っている「データベースの正規化」とまったく逆のことを行うことで、超高負荷のかかる環境下におけるスピードを改善する手法である。
== 概要 ==
データの重複をなくし整合的にデータを取り扱えるようにデータベースを設計することを「[[データベースの正規化]]」と呼ぶ。
教科書に書いてある定番のウリ文句であり、情報系の学校では「データベースを設計するときは正規化しよう」と習うことだろう。
{| class='wikitable'
|+
! メーカー !! 住所
|-
| A社 || 北海道
|-
| B社 || 青森県
|}
{| class='wikitable'
|+
! 商品ID !! 商品名
|-
| 101 || メロン
|-
| 102 || ハスカップ
|-
| 103 || りんご
|}
その逆に1つのテーブルに全部詰め込む手法を「データベースの非正規化」と呼ぶ。
{| class='wikitable'
|+
! メーカー !! 住所 !! 商品名
|-
| A社 || 北海道 || メロン
|-
| A社 || 北海道 || ハスカップ
|-
| B社 || 青森県 || りんご
|}
こちらは主に膨大な量のレコードを扱う[[ITドカタ]]の現場で使われる教科書クソ食らえな必殺技である。
数億レコードを突破するようなテーブルがいくつも存在する現実的な環境下ではテーブルのJOINなどしたらシステムは窒息死するため、このようなデータベースの設計となる事が多い。
非正規化という諸刃の剣に手を出すのは以下のようなケースが多い。
# 正規化した状態で設計・開発する
# サービス開始直後に過負荷でシステムダウン
# 非正規を試みる
# [[プログラム]]側の非正規化対応という魔改造で[[デスマーチ]]に陥る
このような炎上するパターンの根底にあるのは「途中での仕様変更」であり、
見積もり段階でしっかりと想定データ量を算出して、必要に応じて最初から非正規化前提で設計および開発しているプロジェクトは成功することが多い。
== 関連項目 ==
* [[ビットマップ・インデックス]]
== 参考文献 ==
{{reflist}}
{{stub}}
== 概要 ==
データの重複をなくし整合的にデータを取り扱えるようにデータベースを設計することを「[[データベースの正規化]]」と呼ぶ。
教科書に書いてある定番のウリ文句であり、情報系の学校では「データベースを設計するときは正規化しよう」と習うことだろう。
{| class='wikitable'
|+
! メーカー !! 住所
|-
| A社 || 北海道
|-
| B社 || 青森県
|}
{| class='wikitable'
|+
! 商品ID !! 商品名
|-
| 101 || メロン
|-
| 102 || ハスカップ
|-
| 103 || りんご
|}
その逆に1つのテーブルに全部詰め込む手法を「データベースの非正規化」と呼ぶ。
{| class='wikitable'
|+
! メーカー !! 住所 !! 商品名
|-
| A社 || 北海道 || メロン
|-
| A社 || 北海道 || ハスカップ
|-
| B社 || 青森県 || りんご
|}
こちらは主に膨大な量のレコードを扱う[[ITドカタ]]の現場で使われる教科書クソ食らえな必殺技である。
数億レコードを突破するようなテーブルがいくつも存在する現実的な環境下ではテーブルのJOINなどしたらシステムは窒息死するため、このようなデータベースの設計となる事が多い。
非正規化という諸刃の剣に手を出すのは以下のようなケースが多い。
# 正規化した状態で設計・開発する
# サービス開始直後に過負荷でシステムダウン
# 非正規を試みる
# [[プログラム]]側の非正規化対応という魔改造で[[デスマーチ]]に陥る
このような炎上するパターンの根底にあるのは「途中での仕様変更」であり、
見積もり段階でしっかりと想定データ量を算出して、必要に応じて最初から非正規化前提で設計および開発しているプロジェクトは成功することが多い。
== 関連項目 ==
* [[ビットマップ・インデックス]]
== 参考文献 ==
{{reflist}}
{{stub}}
