「データベースの非正規化」の版間の差分
ナビゲーションに移動
検索に移動
(→概要) |
|||
2行目: | 2行目: | ||
== 概要 == | == 概要 == | ||
+ | === 正規化 === | ||
データの重複をなくし整合的にデータを取り扱えるようにデータベースを設計することを「[[データベースの正規化]]」と呼ぶ。 | データの重複をなくし整合的にデータを取り扱えるようにデータベースを設計することを「[[データベースの正規化]]」と呼ぶ。 | ||
教科書に書いてある定番のウリ文句であり、情報系の学校では「データベースを設計するときは正規化しよう」と習うことだろう。 | 教科書に書いてある定番のウリ文句であり、情報系の学校では「データベースを設計するときは正規化しよう」と習うことだろう。 | ||
24行目: | 25行目: | ||
|} | |} | ||
− | + | === 非正規化 === | |
その逆に1つのテーブルに全部詰め込む手法を「データベースの非正規化」と呼ぶ。 | その逆に1つのテーブルに全部詰め込む手法を「データベースの非正規化」と呼ぶ。 | ||
{| class='wikitable' | {| class='wikitable' | ||
38行目: | 39行目: | ||
こちらは主に膨大な量のレコードを扱う[[ITドカタ]]の現場で使われる教科書クソ食らえな必殺技である。 | こちらは主に膨大な量のレコードを扱う[[ITドカタ]]の現場で使われる教科書クソ食らえな必殺技である。 | ||
数億レコードを突破するようなテーブルがいくつも存在する現実的な環境下ではテーブルのJOINなどしたらシステムは窒息死するため、このようなデータベースの設計となる事が多い。 | 数億レコードを突破するようなテーブルがいくつも存在する現実的な環境下ではテーブルのJOINなどしたらシステムは窒息死するため、このようなデータベースの設計となる事が多い。 | ||
− | |||
非正規化という諸刃の剣に手を出すのは以下のようなケースが多い。 | 非正規化という諸刃の剣に手を出すのは以下のようなケースが多い。 |
2017年5月1日 (月) 01:34時点における版
データベースの非正規化とは、データベースの教科書に載っている「データベースの正規化」とまったく逆のことを行うことで、超高負荷環境下での性能改善を試みる手法である。
概要
正規化
データの重複をなくし整合的にデータを取り扱えるようにデータベースを設計することを「データベースの正規化」と呼ぶ。 教科書に書いてある定番のウリ文句であり、情報系の学校では「データベースを設計するときは正規化しよう」と習うことだろう。
メーカー | 住所 |
---|---|
A社 | 北海道 |
B社 | 青森県 |
商品ID | 商品名 |
---|---|
101 | メロン |
102 | ハスカップ |
103 | りんご |
非正規化
その逆に1つのテーブルに全部詰め込む手法を「データベースの非正規化」と呼ぶ。
メーカー | 住所 | 商品名 |
---|---|---|
A社 | 北海道 | メロン |
A社 | 北海道 | ハスカップ |
B社 | 青森県 | りんご |
こちらは主に膨大な量のレコードを扱うITドカタの現場で使われる教科書クソ食らえな必殺技である。 数億レコードを突破するようなテーブルがいくつも存在する現実的な環境下ではテーブルのJOINなどしたらシステムは窒息死するため、このようなデータベースの設計となる事が多い。
非正規化という諸刃の剣に手を出すのは以下のようなケースが多い。
このような炎上するパターンの根底にあるのは「途中での仕様変更」であり、 見積もり段階でしっかりと想定データ量を算出して、必要に応じて最初から非正規化前提で設計および開発しているプロジェクトは成功することが多い。