「データベースの非正規化」の版間の差分
Administrator (トーク | 投稿記録) 編集の要約なし |
|||
| (2人の利用者による、間の3版が非表示) | |||
| 4行目: | 4行目: | ||
=== 正規化 === | === 正規化 === | ||
データの重複をなくし整合的にデータを取り扱えるようにデータベースを設計することを「[[データベースの正規化]]」と呼ぶ。 | データの重複をなくし整合的にデータを取り扱えるようにデータベースを設計することを「[[データベースの正規化]]」と呼ぶ。 | ||
データベースの教科書に書いてある定番のウリ文句であり、情報系の学校では「データベースを設計するときは正規化しよう」「テーブルはJOINで結合して使おう」と習うことでしょう。 | |||
{| class= | {| class="wikitable" | ||
|+ | |+ | ||
! メーカー !! 住所 | ! メーカー !! 住所 | ||
| 14行目: | 14行目: | ||
|} | |} | ||
{| class= | {| class="wikitable" | ||
|+ | |+ | ||
! 商品ID !! 商品名 | ! 商品ID !! 商品名 | ||
| 26行目: | 26行目: | ||
=== 非正規化 === | === 非正規化 === | ||
その逆に1つのテーブルに重複クソ食らえで全てを詰め込む手法を「データベースの非正規化」と呼ぶ。 | |||
{| class= | {| class="wikitable" | ||
|+ | |+ | ||
! メーカー !! 住所 !! 商品名 | ! メーカー !! 住所 !! 商品名 | ||
| 40行目: | 40行目: | ||
数億レコードを突破するようなテーブルがいくつも存在する現実的な環境下ではテーブルのJOINなどしたらシステムは窒息死するため、このようなデータベースの設計となる事が多い。 | 数億レコードを突破するようなテーブルがいくつも存在する現実的な環境下ではテーブルのJOINなどしたらシステムは窒息死するため、このようなデータベースの設計となる事が多い。 | ||
ただし非正規化は諸刃の剣であるということを忘れてはならない。途中での方針変換による採用は非常に危険である。 | |||
# 正規化した状態で設計・開発する | # 正規化した状態で設計・開発する | ||
# サービス開始直後に過負荷でシステムダウン | # サービス開始直後に過負荷でシステムダウン | ||
2023年7月24日 (月) 02:21時点における最新版
データベースの非正規化とは、データベースの教科書に載っている「データベースの正規化」とまったく逆のことを行うことで、超高負荷環境下での性能改善を試みる手法である。
概要[編集 | ソースを編集]
正規化[編集 | ソースを編集]
データの重複をなくし整合的にデータを取り扱えるようにデータベースを設計することを「データベースの正規化」と呼ぶ。 データベースの教科書に書いてある定番のウリ文句であり、情報系の学校では「データベースを設計するときは正規化しよう」「テーブルはJOINで結合して使おう」と習うことでしょう。
| メーカー | 住所 |
|---|---|
| A社 | 北海道 |
| B社 | 青森県 |
| 商品ID | 商品名 |
|---|---|
| 101 | メロン |
| 102 | ハスカップ |
| 103 | りんご |
非正規化[編集 | ソースを編集]
その逆に1つのテーブルに重複クソ食らえで全てを詰め込む手法を「データベースの非正規化」と呼ぶ。
| メーカー | 住所 | 商品名 |
|---|---|---|
| A社 | 北海道 | メロン |
| A社 | 北海道 | ハスカップ |
| B社 | 青森県 | りんご |
こちらは主に膨大な量のレコードを扱うITドカタの現場で使われる教科書クソ食らえな必殺技である。 数億レコードを突破するようなテーブルがいくつも存在する現実的な環境下ではテーブルのJOINなどしたらシステムは窒息死するため、このようなデータベースの設計となる事が多い。
ただし非正規化は諸刃の剣であるということを忘れてはならない。途中での方針変換による採用は非常に危険である。
このような炎上するパターンの根底にあるのは「途中での仕様変更」であり、 見積もり段階でしっかりと想定データ量を算出して、必要に応じて最初から非正規化前提で設計および開発しているプロジェクトは成功することが多い。