データベースの論理削除と物理削除
データベースからデータを削除するには、「論理削除」と「物理削除」2種類の方法がありまります。
物理削除とは文字通りDELETE構文を利用しデータベースよりレコードを完全に削除してしまうことをです。
論理削除とは、データベースにフラグとなるフィールドを作成しておき、削除時に削除フラグを立てることにより、仮想的に表示時に見えなくしてしまう処理になります。
私がデータベース設計を行う際には論理削除を採用するのですが、論理削除のメリットデメリットをまとめておきたいと思います。
論理削除のデメリットが、物理削除のメリットになります。
論理削除
メリット
- 誤ってDBからデータが削除された場合に簡単に復元できる
デメリット
- 表示時にWHERE句にフラグの確認が必要になる
- 削除処理をUPDATE構文で行う為、非直感的である
- レコードが肥大し続ける為データベースのコストパフォーマンスを損なう恐れがある。
(一定期間後に削除フラグが付いたデータを削除する時効処理を施せばある程度改善できる) - DB設計が若干複雑になる
- データに個人情報が含まれる場合は、削除データの保持は問題が発生することもある
うーん。
あんまりメリットが見出せなかったが、「削除されたデータの復元」がデメリットを理解したうえで、私が論理削除を採用するに値するメリットになっています。
誤ってDBからデータが削除されるケースとして、「顧客が誤って削除する」と「システムのバグで削除する」のが考えられます。
基本的に論理削除は「顧客が誤って削除する」に対応する為に採用しているのではないです。
(サービスやオプションとして誤って削除したデータの復元を行う場合もあるのですけども)
システムのバグで削除された場合に調査、復元が容易だということで採用しています。
理想はケースバイケース(処理ベースではなく案件ベース)で使い分けるのが良いと思うのですが、他のプログラマーさんはどのように書いてるのでしょう?
ちょっと気になったのでエントリーしてみました。コメントやトラックバック、ソーシャルブックマークでご意見いただけたらうれしいです。
スポンサードリンク
«feed meterに参加しました。 | メイン | Slice Imageでサイトを高速化»
- このエントリーのトラックバックURL
- http://blog.webcreativepark.net/cgi/mt/mt-bt.cgi/501
- トラックバック内容
-
» データベースの論理削除と物理削除
from サラトガ牧場
何気なく RSS に登録したブログを見ていたら、 こんな記事を発見。 [to-R]



西畑一馬(



論理削除と物理削除のいいとこ取りを狙った、削除テーブルにコピーするという方法を最近よく採用してます。
user_mst テーブルに対して、deleted_user_mst テーブルを用意しておいて、ユーザの削除時は、user_mst テーブルから DELETE すると同時に、deleted_user_mst テーブルに INSERT するという方法です。
deleted_user_mst テーブルには、user_mst テーブルと同じカラムの他、削除テーブル独自のプライマリーキーと、削除日時のカラムと多人数で使用するシステムの場合は、削除操作を行ったユーザIDなどを追加します。
この方法を使う頃で、論理削除のメリットを享受しつつ、デメリットを減らす事が出来ます。
新たに発生するデメリットは、追加するテーブルが増えてしまう事と、削除を行うロジックが複雑になってしまう事でしょうか。
デメリットもそれなりにあるので、最悪失われてしまっても良いものは物理削除、絶対に間違って失いたくないものは削除テーブルという風に、使い分けています。
>Otchyさん
レコードの肥大と誤削除に対応した、ハイブリットな良い感じですね。
やっぱりロジックを複雑が複雑になっても、最善を尽くすのが良いですよね。
参考になりました。ありがとうございます。
基本的にほぼ全て物理削除にしています。
論理削除のメリットの部分である、「復旧が容易」という部分は理解しているのですが、そこのメリットを享受するよりは、削除周りのロジックをしっかり組んで、(特に)使用者が間違った操作で削除を行わないように気をつけるようにしています。
開発時はこまめにバックアップを取るとかですかねぇ。
でも場合によっては論理削除を組み込んでるときもありますが、考えてみたら明確なポリシーは無さそうです…
はじめまして
論理削除のメリットとして、削除処理と更新処理が同時実行されたとき、楽観的ロックで制御できるなんてのはどうでしょうか。
>いたさん
「削除周りのロジックをしっかり組んで」
確かに。。。ここをさぼってして論理削除を導入しているの感はありますね。
テストや検証の工数が取れない場合、もしシステムにバグがあったらってのが気になってしまう所ですが。
>flakwingさん
楽観的ロックですか。考えたことなかったです。
(気にする規模のDBを操作したことがないので。)
ちょっとここら辺はあまり理解してないので勉強しなおします。