過去の関連記事
論理削除とは
- DBのレコードを物理的に削除せず「削除フラグ」をONにする
- SELECTするときに削除フラグ=falseのもののみ取得する
SIerの現場では日常的に用いられるアンチパターン
論理削除の問題点
- 削除フラグをWHERE条件に漏らしたらバグになる
- JOINが重なると更に深刻
- ユニーク制約が貼れない
- レコード数の増大
- クラウドDBでは費用に直結
- SELECT時の走査レコード数が費用になるケースもある
総じて、SELECT時に重い負荷となる
なぜ論理削除したいのか
- 業務要件として
- 一般ユーザーには見えないように
- 過去データの参照
- 誤って削除したときに戻せるように
- 運用上の要件として
- 万一必要になった場合に備えて
- 参照整合性制約違反となるのが辛い
論理削除フラグは最適解か？
- 一般ユーザーには見えないように
→ 権限によるアクセス管理が適当 - 過去データの参照
→ 期日によるアクセス管理が適当
→ スナップショットを別テーブルに残す - 誤って削除したときに戻せるように
→ UIで抑止：確認ダイアログ／一定時間は戻せるようにする - 万一必要になった場合に備えて
→ バックアップから戻す、ログを見るなど代替手段がある - 産業整合性制約違反となるのが辛い
→ データ依存を理解し、削除手順を設計する
業務アプリの現実
- テーブル数が100を超えることも珍しくない
- このような中、テーブル毎に最適な削除手法を選択するのは大変
しかし・・・削除フラグを導入していい理由にはならない！
代替手段
- 退避テーブル ←イチオシ
- Blobコンテナなどへの退避も有り得る
- バックアップの活用
最後に
- テーブルを再設計できる機会は少ないと思いますが、問題点を認識しておくのは大事
- 改善の機会が訪れたときに備えて、良い設計を勉強しておきましょう
- RDBの設計パターンってほんっと面白いですよ！
来週は楽観ロックの話をします。