論理削除と物理削除 — 「消した」を、すべてのクエリが覚えていられるか

What — 行を消すか、印を付けるか

削除には2つのやり方があります。

• 物理削除 — DELETE で行そのものを消す。テーブルから無くなる
• 論理削除 — 行は残し、「削除済み」の印（deleted_at や is_deleted）を付ける。読むときに印の付いた行を除く

一見、論理削除は「消さないだけ」の安全な選択に見えます。ところが、「削除」という事実の置き場所が変わっています。

DELETE FROM members WHERE id = 42

物理削除

DELETE で行そのものを消すこと。ハードデリートとも呼ぶ。

論理削除

行を残したまま、削除済みの印を付けること。ソフトデリートとも呼ぶ。

一意制約

列の値がテーブル内で重複しないことを DB が保証する制約。

部分インデックス

条件を満たす行だけを対象にするインデックス。使える DB と使えない DB がある。

Why — なぜ事故になるのか

物理削除では、「その行はもう無い」という事実を DB が守っています。消えた行はどの SELECT にも出てきません。書き忘れようがありません。

論理削除にすると、この事実は DB の外に出ます。「deleted_at が入っている行は無いものとして扱う」という約束に変わり、その約束を守るのは、テーブルを読むすべてのクエリです。

物理削除:  DB が「無い」を保証する   → 読む側は何も知らなくてよい
論理削除:  読む側が「無い」を再現する → 読む側全員が約束を知っている必要がある

アプリのコードだけなら、レビューや共通の関数で守れるかもしれません。ところがテーブルを読むのはアプリだけではありません。配信ツール、分析基盤、管理画面、障害対応で誰かが手で書く SQL。 その全員が約束を知っていることは、誰も保証していません。

制約も、削除を知らない

冒頭のもう1つの事故、再登録できない問題も同じ根から来ています。

一意制約も外部キーも、DB の上の「行」について約束するものです。deleted_at は、DB から見ればただの列の1つにすぎません。

• 一意制約 は、削除済みの行も数える。再登録が弾かれる
• 外部キー は、削除済みの親を「存在する」と見なす。退会した会員の注文も、参照先が有効なまま残る
• インデックス は、削除済みの行も含めて大きくなる。削除済みが9割のテーブルでも、索引は10割ぶん

「消した」と言える状態か

論理削除した行には、氏名もメールアドレスも住所も残っています。アプリの画面から見えないことと、消えていることは別です。

個人情報保護法には、利用する必要がなくなった個人データを遅滞なく消去するよう努める、という規定があります。「退会したので消しました」と利用者に説明するなら、少なくとも個人を特定できる情報は、実際に消えているか、特定できない形に置き換わっている必要があります。

論理削除を選ぶとき、ここが最も見落とされます。「戻せるから安全」は、運営者にとっての安全で、利用者にとっての安全ではありません。

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。