作成日:  (更新日: )

DB データの論理削除

このページは、DB データの論理削除について考えるページです。

目次

注意

  • このページを作ったひとが現在進行形で考えていることのため随時内容が変わることがあります。

「論理削除」？

  • DELETE 文での削除ではなく、削除フラグ列 (または削除日など「削除」を意図した列) を UPDATE することで削除したことを表現する方式
  • DELETE 文での削除は「物理削除」と呼ばれる
例: 削除フラグを持つ商品マスタ。削除したいデータは削除フラグ = 1 とする
  • 「アプリケーション上はデータが削除された状態にしたい」「DB 上はデータをいつでも戻せるように残したい」を簡単に両立させたい時に使う

設計時に検討すること

論理、物理にかかわらず「削除」という表現・行為自体が対象業務上適切なのか

  • 実際には削除ではないものを削除と決めつけていないか
    • 例: 非表示、無効、停止 (一時停止)、終了、完了、却下、否認、失注
    • 例: 社員の退職
      • 「社員マスタ」は「在職中の社員の集合」だけを有標する (特別に表している) わけではない
        • 変更履歴データと違って退職した社員データは「退職した」という状態の現在データ (復職して在職状態に戻る可能性もある)
        • 単純に削除すると削除した社員データに紐づく従属データに影響が出る場合がある
          (退職した社員が販売担当者として紐づいている売上データなど。論理削除方式にすれば影響が少ないが、そもそも削除という扱い方が適切でない)
    • 例: 商品の取扱終了
      • 「商品マスタ」は「現在取扱中の商品の集合」だけを有標するわけではない (社員の退職と同様)

「削除フラグ」という表現が設計として適切なのか

  • 削除フラグは表現できる事象が少ない (「削除されているか」しか判別できない)
例 表現できる事象
削除フラグ ・削除されているか
削除日 ・削除されているか
・削除した日 (いつ削除されたか)
状態 (ステータス) ・どの状態になっているか (「投稿記事」であれば「下書き」「レビュー待ち」「公開」「限定公開」「非公開」など、状態数分の表現ができる)
適用開始日・終了日 ・適用前・中・後か
・適用終了した日 (いつ適用終了にされたか)
  • 「削除フラグ」「削除日」は削除を意図しているので論理削除にあたるが、「状態」などは論理削除ではない
    • 「状態」の中に「削除」という項目を設けた場合は論理削除になり得るが、状態を設けること自体がただちに論理削除ということではない

物理削除すべきデータか

  • ユーザーが誤操作で作成してしまったデータ　(下書き、未承認データなど) は特段の事情がなければ物理削除できたほうがいい
    (データ容量が無駄)
  • ユーザビリティの観点上、1回目の削除で 「状態」 = 「削除待ち」(ゴミ箱) にしておいてから別の操作で物理削除する or 復帰させる方式はあり得る
    • 単純な論理削除 (削除フラグ) 方式で開発するとアプリケーション上は物理削除と同じ UI 表現になるので DB ユーザーがシステム外で削除フラグを戻すなどの運用が発生する場合がある
  • 業務上正式に使用しているデータ (承認フローを通過したデータなど) はそもそも「削除」という扱いが適切でない場合がある
    (論理削除・物理削除に関わらず意味が違うので別の状態として扱ったほうがいい)

その他

  • 「削除フラグがあると一意性制約 (ユニーク制約) が設定できない」ということはない

参考