📑
データのライフサイクル（作成・更新・削除）が明確か？
データのライフサイクル（作成・更新・削除）が明確か？
背景・概要
データは**作成 → 更新 → 削除（または無効化）**といった一連の流れを持つ
これが設計段階で不明瞭だと、整合性の欠如・不要な肥大化・運用不能なデータ構造などを招く
例
- 業務上の復元ニーズを考慮してdeleted_at カラムで論理削除を管理する
- 「下書き → 承認 → 公開」のような状態遷移をステータスで管理する
- 作成者・更新者・更新日時を業務利用するので非システムカラムとしてcreated_by, updated_by, updated_at で保持
よくある失敗例
- 論理削除と物理削除の基準が曖昧で、不要なデータが溜まり続ける
- 同じエンティティに削除済み・最新状態・下書きなどが混在しており管理不能
- 更新日時が存在せず、どのデータが最新かわからない
FAQ
Q. 論理削除と物理削除、どちらを使うべき？
A. ケースバイケース。非同期処理では論理削除の Update より Delete → Insert の方が考慮事項が少ないことが多い。一方で、業務上の復元ニーズがある場合は論理削除が望ましい。論理削除をトラブル時のログとしても活用したいなら、そもそも専用のログテーブルを設ける方が保守性・検索性の面で優れる。また非構造化データであるログの保存はRDBよりCloud Storage・Amazon S3・Azure Blob Storageのような媒体を使用することを推奨する
Q. 更新履歴はどこまで管理すべき？
A. これもケースバイケース。updated_at による直前の変更履歴だけで済むケースと、**監査ログのように全履歴を残す必要がある業務も存在する。**後者の場合は専用テーブルを検討されたい
関連観点
- データ更新時の排他制御・ロック戦略が適切に設計されているか？
- マイグレーションの影響が考慮され、安全な実施計画があるか？
- 不整合なデータが発生しないように、適切なバリデーションが行われているか？
- 必要な正規化・非正規化のバランスが適切に設計されているか？
📘 本記事は SaaS設計レビュー観点チェックリスト（2025年版） の一部です。
設計観点カテゴリ：📦 データ
レベル：Structure（構造・原則・責務整理レベル）
推奨読者：設計初心者 / 設計中のチーム / レビュワー
🧭 他の観点もまとめて読みたい方はこちらからどうぞ。
Discussion