技術顧問や講演の場で、論理削除について見解を聞かれる場面がよくあります。アプリケーション開発者の方にとって、身近なデータベースの疑問なんでしょうね。
しっかり言語化できてなかったので、ブログに書いておきます。
論理削除をどう考えるかは、諸派あるんだろうと思ってます。 自分の意見が正しいと言うつもりはありませんし、求めらる要件や環境で結論が変わることもあると思います。
論理削除とは(おさらい)
以下のように削除日付(deleted_at)のカラムを設けて、レコードの有効・無効を管理する手法を指します。
id | name | deleted_at |
---|---|---|
1 | aaaaaa | NULL |
2 | bbbbbb | 2021-01-12 10:00:00 |
論理「削除」と呼びますが、実際は、非表示フラグやレコードの状態遷移を表していたり。よくよく考えると「削除」でないパターンも含まれています。逆に、DELETE
して完全にデータを削除することを「物理削除」と呼びます。
誤操作の取り消しが、論理削除を採用する代表的な目的でしょう。
誤操作の保険としてはバックアップもありますが、バックアップは、データベース全体の時間軸を戻すことを意図したものです。 特定のレコードに絞って時間軸を戻すのには適していません。
論理削除のデメリットと言われているもの
バグの温床になりやすい
WHERE
句に deleted_at IS NULL
を付けまくらないといけないというやつですね。deleted_at IS NULL
を付け忘れると削除済みデータが見えてしまうと。
パフォーマンスへの影響
本来必要のないレコードが保存されることで、そのぶんオーバーヘッドになる。
ぼくの見解
論理削除をそれほど、強いアンチパターンだとは考えてません。他のアンチパターンと比較すると問題になる確率も低いように思います。 自分の周囲では論理削除が問題になっているケースをほとんど見たことがないです。
もちろん物理削除のほうがデータがクリーンで好ましいと思います。ただ、論理削除を撲滅するために、大きな労力を割く必要は感じないです。
パフォーマンス影響については、論理削除の有無より他の要素に左右されるケースがほとんどだと思います。
むしろ、現場では、貯め続けていると、そのうち明らかに問題になるデータ量なのに、ノーガードで運用されているケース に出くわすほうが多いです。論理削除云々を気にする以前に、データ量の見積もりと、適切なデータストアの選定をしっかりしてほしい。。。*1
*1:あと、物理削除バッチの作りが悪くて、爆発することも多い