Hello there, ('ω')ノ
データを扱っていると、必ず直面するのが「データの更新」に関する悩みです。 たとえば、顧客の住所が変わった、商品の価格が改定された、ステータスが更新された── そんなとき、「前のデータを上書きしていいのか？」「それとも履歴として残すべきか？」という判断が必要になります。
✅ データ更新の2つの方法
データを更新する方法には、主に以下の2つの考え方があります。
| 方法 | 内容 | 向いているケース |
|---|---|---|
| 上書き方式 | 最新の情報で過去データを上書きする | 管理がシンプルな場合 |
| 履歴保持方式 | 過去データを残して新しい行を追加 | 時系列分析やトレースが必要な場合 |
🔁 ① 上書き方式（Overwriting）
どういうこと？
同じ行の中のデータをそのまま書き換える方法です。
例：
| 顧客ID | 住所 |
|---|---|
| A001 | 東京都渋谷区 |
→ 引っ越し後：
| 顧客ID | 住所 |
|---|---|
| A001 | 神奈川県横浜市 |
これで完了。シンプルで手軽ですが、過去の情報は完全に失われます。
✅ メリット：
- 管理が簡単
- データ量が増えない
❌ デメリット：
- 履歴が追えない
- 変更の記録を残すには、別システムが必要
📚 ② 履歴保持方式（履歴テーブル、SCD）
どういうこと？
更新があった場合、新しい行として追加し、過去の状態も残す方法です。
例：
| 顧客ID | 住所 | 開始日 | 終了日 |
|---|---|---|---|
| A001 | 東京都渋谷区 | 2023-01-01 | 2024-12-31 |
| A001 | 神奈川県横浜市 | 2025-01-01 | （現在） |
こうすることで、「いつどこに住んでいたか」が明確になります。
✅ メリット：
- 過去の状態がわかる
- 時系列分析（売上変動、顧客移動など）が可能
- 調査や監査に強い
❌ デメリット：
- テーブルが肥大化しやすい
- クエリ（SQL）が複雑になる
- 管理ルールが必要（バージョン管理など）
🧠 「SCD」って何？
履歴保持方式には「SCD（Slowly Changing Dimension）」という有名な設計パターンがあります。
| タイプ | 概要 | 使用例 |
|---|---|---|
| SCD Type 1 | 上書きのみ（履歴を残さない） | ただの誤字修正など |
| SCD Type 2 | 履歴を残す（開始日・終了日で管理） | 顧客情報や部署異動など |
| SCD Type 3 | 過去データを一部だけ保持（例：最新＋1件前） | 一時的な比較用途 |
SCD Type 2 が、最も履歴を詳細に残せる一般的な方法です。
🏢 実務での選び方は？
| 判断基準 | おすすめ方式 |
|---|---|
| 管理が簡単でいい → 最新だけ見られればいい | ✅ 上書き方式（Type 1） |
| 顧客がいつどこにいたかを把握したい | ✅ 履歴保持方式（Type 2） |
| 定期的にデータが変わる（住所、部署、契約内容など） | ✅ Type 2 or Type 3 |
| 変更履歴のログが別に記録されている | → 上書き＋ログ保存も可 |
💡 どちらを選んでも「意図とルール」が大切
重要なのは、「なぜその方式を選んだのか」を明確にして、全員がそのルールを共有していることです。
- 履歴を取るのに必要な列（開始日・終了日・バージョン番号）を設計する
- 古いデータの保存期間や削除ルールを定める
- 分析に使うときは「最新レコードだけ抽出する」SQLを書く
こうした運用ルールが整っていれば、どちらの方式でもトラブルを回避できます。
✨ まとめ：「履歴は残すべきか？」は業務による
| 方針 | 内容 |
|---|---|
| 上書き方式 | 単純で高速。履歴は残らない |
| 履歴保持方式 | 変化を追える。設計・運用が必要 |
| 決め手 | 「変化の記録」が必要かどうか |
Best regards, (^^ゞ
