データのライフサイクル（作成・更新・削除）が明確か？¶
Type: Structure
Category: データ
Audience: 設計初心者 / 設計中のチーム / レビュワー
背景・概要¶
データは作成 → 更新 → 削除（または無効化）といった一連の流れを持つ
これが設計段階で不明瞭だと、整合性の欠如・不要な肥大化・運用不能なデータ構造などを招く
例¶
- 業務上の復元ニーズを考慮して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 による直前の変更履歴だけで済むケースと、監査ログのように全履歴を残す必要がある業務も存在する。後者の場合は専用テーブルを検討されたい