データベースの論理削除と物理削除

データベースの論理削除と物理削除

データベースデータベースの論理削除と物理削除

何気なく RSS に登録したブログを見ていたら、こんな記事を発見。

[to-R]データベースの論理削除と物理削除

物理削除は、SQL の DELETE でテーブルからデータを削除してしまうこと。論理削除はテーブルのカラムに削除フラグなるものを持って、そのフラグの値によって振る舞いを変えることです。例えばフラグが 0 の時は画面に表示して、1 の時は見せないなど。
(SQL では DELETE しないで、UPDATE でフラグの値だけ変更します)

さて、この問題ですが、仕事の内容(案件都合)や、データの重要度、データベースの種類によって設計は変わってきそう。昔、とある携帯キャリアのポータルサイトを仕事でやっていた時は、会員情報(会員テーブル)は退会時に履歴テーブルに移して、会員テーブルからは物理削除していた。

会員テーブルは参照と更新の頻度が多いので、データ量(ここではレコード数)は極力減らしたいという思いが強かったからだったと記憶している。しかし、会員の過去を追わなければならない場面もあるので、履歴テーブルに入会や退会、個人の情報も残していた。
(ログ解析のデータとしても利用していたので)

しかし、このサイト(サラトガ牧場)の各コンテンツでは、すべて論理削除を前提として設計しました。理由は大きく 2 つで、1 つは管理画面で削除処理を作るのが面倒だったから。
(更新処理はどうせ必要だし)

もう 1 つは、serial(auto_increment) を使ったテーブルは物理削除をしたくないという気分的なもの。昔、MySQL で auto_increment を使ったテーブルのレコードを削除したときに、データベースエンジンが InnoDB か MyISAM で MySQL のサービス再起動後の挙動が変わるという現象があったから。
(片方は auto_increment 値が現在の最大のものになるんだったっけな)

どちらにせよ、完全にデータを消してしまうのは怖いけど、個人情報は持ち続けたくないという難しい問題にぶち当たる。
(個人情報保護法ができてから特に意識が変わったかな)

データベースのバックアップデータや、最低限のログがサーバに残っていればデータベースからは削除してしまってもいいと思うけど、お客さんありきの仕事だと安易に決めれないですね。

私が設計する場合は、マスタデータは論理削除に対応させて、トランザクションデータは物理削除かなぁ。まあ、もちろん状況によりけりなので結論ではないのですが。っと、まとまりのない内容になってしまいましたが、日頃の何気ないこともじっくりと考えてみると難しいですね。

最終更新日:

関連記事

人気記事

新着情報