はじめに
社内の輪読会で『失敗から学ぶRDBの正しい歩き方』の第1章「データベースの迷宮」と第2章「失われた事実」を担当しました。本記事では、その際に作成した資料を公開します。
1章 データベースの迷宮
データベースのカラムの命名アンチパターン
❌️ 何を意味するのか分からない
memo1
memo2
memo3
...
❌️ タイポしてる
customar_name
uesr
❌️ 入ってる値が何を意味するか分からない
0
1
2
99
null
❌️ 制約が無い
- PRIMARY KEY
- NOT NULL
- UNIQUE
- CHECK
- DEFAULT
- FOREIGN KEY（外部キー）
問題
データベースを読み解けないことで、改修が困難になってしまう
対策
✅️ 初期段階で対処する
✅️ 制約を利用する
✅️ 将来を想定して命名する
例）実装時はphone_numberで良かったけど、後からhome_phone_numberとmobile_phone_numberが加わる
まとめ
データベースはアプリケーションより寿命が長く、技術的負債が貯まりやすいため、早めに対処することが大事‼️
2章 失われた事実
履歴の保存が大事
- どのような過程で今の値になったのか分からない
- データを戻せない
履歴が無いと、過去の過程が失われる
❌️ 最後の結果は同じでも過程が異なる
例）受注ステータス
新規受付→発送前入金待ち→発送待ち→処理済
新規受付→処理済
対策
✅️ 履歴を保存する
例）受注ステータスの変更履歴を持たせる
| id | 受注ステータス | 作成日時 |
|---|---|---|
| 1 | 新規受付 | 2025-11-04 09:14:10 |
| 1 | 発送前入金待ち | 2025-11-04 10:10:00 |
| 1 | 発送待ち | 2025-11-04 15:52:38 |
| 1 | 処理済 | 2025-11-07 12:00:00 |
| 2 | 新規受付 | 2025-11-07 12:24:30 |
| 2 | 処理済 | 2025-11-10 14:41:55 |
注意
パフォーマンスが悪くなるため、注意が必要です
- レコードの保存量が増えるとテーブルサイズが増える
- 集計が単純な主キーでないため、検索速度が遅くなる
→対策として、マテリアライズド・ビューや集計済み結果を保存したサマリーテーブルを作成する
マテリアライズド・ビューとは？
マテリアライズド・ビューを一言で言うと、「クエリ結果を物理的に保存したビュー（仮想テーブル）」です。
通常のビューが、参照されるたびに定義されたSQLを実行して結果を動的に生成するのに対し、マテリアライズド・ビューは、その結果のデータ自体を複製し、データベース内に専用のテーブルとして保持します。
| 特徴 | マテリアライズド・ビュー | 通常のビュー |
|---|---|---|
| データの保持 | 保持する（物理的な実体がある） | 保持しない（定義のみ） |
| 参照時の処理 | 保存されたデータを読み込む | 定義されたSQLを毎回実行する |
| 最新性 | リフレッシュ（更新）が必要 | 常に最新のデータが反映される |
サマリーテーブルとは？
サマリーテーブルとは、元の詳細なデータ（トランザクションデータなど）を事前に集計・加工し、その結果だけを保存したテーブルのことです。
「集計済み結果を保存したテーブル」という表現が、このテーブルの役割を最も正確に表しています。
| 特徴 | サマリーテーブル | 元の詳細テーブル |
|---|---|---|
| データの粒度 | 粗い（集計済み） | 細かい（一件一件の取引など） |
| 行数 | 少ない | 多い（大量） |
| クエリ速度 | 非常に速い | 複雑な集計は時間がかかる |
| 用途 | ダッシュボード、定型レポート、頻繁な分析 | 詳細な調査、イレギュラーな分析 |
まとめ
- 取り消し処理（戻し処理）に対応できるか？
- 値の変更の過程を追えるか？
- トラブル時に必要な情報が見られるか？
最後に
GoQSystemでは一緒に働いてくれる仲間を募集中です！
ご興味がある方は以下リンクよりご確認ください。