基本へ帰ろう このページをアンテナに追加 RSSフィード

2008-07-15

データベースの論理削除と物理削除について

what

論理削除と物理削除はどっちがいいんだろうね?というお話。



ググってみる

物理削除と論理削除、どっちがいいの? -データベースを使用したシステ- その他(データベース) | 教えて!goo

結論は、

どちらがBetterかはケースによるので、

その場その場でBetterな方法を選択すればよろしいかと。

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

理想はケースバイケース(処理ベースではなく案件ベース)で使い分けるのが良いと思うのですが、他のプログラマーさんはどのように書いてるのでしょう?

うーん。ケースバイケースなんですかねー。



論理削除と物理削除のメリットとデメリット

基本的には、

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

↑こちらと同じ感じです。


論理削除で良い点は、

「データが残っている」ということです。

データがあれば、復元できますし、ユーザーのサポートで使えたりします。

もう少し視野を広げると、ユーザーに被害があった場合等で裁判が発生したりしたとき、

証拠として提出したりする場合もあるかもしれません。

統計としても使えます。

商用で必要なサポートや、社会的な責任を果たしやすいのは論理削除かもしれません。


でも、DB設計が少し複雑になったり、

削除なのに削除してないじゃん!みたいな非直感的な部分があったり、

削除データをいつまでも抱えているので、パフォーマンスが落ちやすいなどデメリットもあります。

ただ、「削除データがあるからパフォーマンスが下がる」というのは考えない方がいいかなと思います。

だって、削除が一つも出なかったらデータ量は変わらないじゃないですか。

まぁ、ちょっとプログラムが複雑になって、メンテナンス性が下がるってのはあるかもしれませんね・・・。


どうなんでしょうね?やっぱケースバイケース?



論理削除と物理削除のいいとこ取りした考え方はないのか?

いいとこ取りというと、


プログラムやデータ管理のシンプルさを保ってメンテナンス性を上げながら、データの保存性もあるということでしょうか。


物理削除と論理削除、どっちがいいの? -データベースを使用したシステ- その他(データベース) | 教えて!goo

↑こちらに書いてあるのですが、

「削除データとそうでないデータを分ける」

という方法でしょうか。


1つの方法としては、

「削除専用テーブルを作って、削除対象データはそちらに移す」

ということでしょうか。

普段動いているテーブルからは物理削除され、いざと言う時には、削除専用テーブルに残っているというものです。


でも、なんかDB設計が複雑になりそうですし、ムダにテーブルが増えそうでなんか微妙な感じです。

プログラムも複雑になりそうで、メンテナンス性が下がりそうです。



なんか良い考え方ないでしょうかね?

つっこみ大歓迎です!