何気なくブログを見ていたら、こんな記事を発見。
物理削除は、SQL の DELETE でテーブルからデータを削除してしまうこと。論理削除はテーブルのカラムに削除フラグなるものを持って、そのフラグの値によって振る舞いを変えることです。例えばフラグが 0 の時は画面に表示して、1 の時は見せないなど。
(SQL では DELETE しないで、UPDATE でフラグの値だけ変更します)
データを残す必要性
さて冒頭の問題ですが、仕事の内容(案件都合)やデータの重要度、データベースの種類によって設計は変わってきそう。
昔、とある携帯キャリアのポータルサイトを仕事でやっていた時は、会員情報(会員テーブル)は退会時に履歴テーブルに移して、会員テーブルからは物理削除していた。
会員テーブルは参照と更新の頻度が多いので、データ量(ここではレコード数)は極力減らしたいという思いが強かったからだったと記憶している。
しかし、調査などで会員の過去の履歴を追わなければならない場面もあるので、履歴テーブルに入会日や退会日、ニックネームなどの個人情報は残していた。
(ログ解析のデータとしても利用していたので)
サイトのポリシー次第
私が趣味で作っているサイトのコンテンツデータは、大半が論理削除を前提として設計しました。
えっ、趣味サイトなら物理削除でいいじゃんっていう人もいるかもしれませんね。
理由は大きく 2 つで、1 つは管理画面で削除処理を作るのが面倒だったから。
(更新処理はどうせ必要だし、そこでフラグ立てればいい)
もう 1 つは、serial(auto_increment) を使ったテーブルは物理削除をしたくないという気分的なもの。
情報を鵜呑みにしない
昔、MySQL で auto_increment を使ったテーブルのレコードを削除したときに、データベースエンジンが InnoDB か MyISAM で MySQL のサービス再起動後の挙動が変わるという現象がありました。
確か記憶では、MyISAM のストレージエンジンで作成したテーブルの場合は、auto_increment 値が現在の最大のものになるんだったっけな(うろ覚え)
この頃は MySQL4 系だったので、今では大きく違う気はする。
個人情報との闘い
どちらにせよ、完全にデータを消してしまうのは怖いけど、個人情報は持ち続けたくないという難しい問題にぶち当たる。
(個人情報保護法ができてから特に意識が変わったかな)
データベースのバックアップデータや、最低限のログがサーバに残っていればデータベースからは削除してしまってもいいと思うけど、お客さんありきの仕事だと安易に決めれないですね。
私が設計する場合は、マスタデータは論理削除に対応させてトランザクションデータは物理削除かなぁ。
個人情報部分が不要だけど調査目的のためにデータが必要な場合は、個人情報部分だけをマスクしちゃうとかね。
もちろん、セキュリティーの担保や個人情報を提供する側との取り決め(規約への同意)など、状況によりけりなので結論は出ないのですが。
っと、まとまりのない内容になってしまいましたが、日頃の何気ないこともじっくりと考えてみると難しいですね。
