ゴミ箱の中のメモ帳

まだ見ぬ息子たちへ綴る手記

データベース内のデータは即時削除すべきかどうか

どこがきっかけだかわからないが、ここ数日同じような質問を何度化受けた。

調べてみると「DELETE_FLAG という思考停止フラグ」や「論理削除が云々について」や「論理削除はなぜ「筋が悪い」か」が原因だろうか。

どうもRDBのレコードの削除をどうするか、レコードの更新は履歴として保持すべきなのかと言うことに悩んでいるようだ。

リレーショナルデータベース入門―データモデル・SQL・管理システム (Information&Computing)

リレーショナルデータベース入門―データモデル・SQL・管理システム (Information&Computing)

 
NOSQLの基礎知識 (ビッグデータを活かすデータベース技術)

NOSQLの基礎知識 (ビッグデータを活かすデータベース技術)

 
Rdb/vms

Rdb/vms

 

 

====
私の解答は単純だ。

基本は削除リクエスト時に即削除、削除フラグを立ててもいいがフラグは1ヶ月(一定期間)以内にバッチなんかで物理削除。履歴は残すな。

 

先の記事とは解答の質が違うがきちんと理由がある。

先の記事では「RDBとしてのパフォーマンス」や「設計上の都合」なんかがベースとなっているが、そんなものはこの国の法律には関係がない。法的な理由に基づき削除リクエスト時に即削除すべきだ。

例えば編集や削除リクエストがブログ記事やコメントなんかのようなライトな情報であれば削除フラグを建てたまま削除しなかろうが、削除したように見せかけて「is_active」なんかで「削除ではなく非表示」にしていようがどうでもいい。

だがユーザ情報だけは即刻削除するか、一定期間毎にクリーニングをかけて物理的に削除しなければならない。そしてユーザ情報の編集履歴も残してはダメで、それも上書きかInsert&Deleteとして削除すべきだ。

 

先の記事では「状態をマスタに持つな」ということであるが、例えばそう考えるのであれば「ユーザの住所」や「電話番号」、「姓」なんかも状態であるからマスタに持たないということだろう。そしてそれを「CRUD」の「UD」を使わず、とにかく追記していけと言うことのようだ。

だがこれはユーザ情報に限っては非常に厄介な法的な問題を生む。

 

一番単純なものは、「個人情報の保護に関する法律」による「開示請求」、「訂正請求」、「削除請求」だろう。

個人情報は先の法律に基づき、サービスの利用規約なんかで利用目的を明示して置かなければならない。そしてその利用目的に応じてそれを利用する必要がある。

よって、「めんどくさいからどんどん追記しちゃうよ」と言うような理由でジャンジャンと個人情報を収集し蓄積することは許されない。もし何らかの理由があり蓄積するにしても、削除が前提であっても6ヶ月以上にわたってそれを蓄積にするのであればその理由が必要に成る。

そして「ユーザからは見えないけど蓄積している」ということも許されない。「開示請求」をだされれば、当該サービス内で保持している個人情報を開示しなければならないが、履歴として保持していれば「保持理由」をなんとしてその情報を開示するのだろうか。

そしてそして、そのように「削除しない」ことを前提にしているシステムで「削除請求」を出された日にはどのように対応するのだろうか。削除請求を出されれば基本的には当該情報を全て削除しなければならない。そういったシステムの場合、個別にSQLで削除を行えばシステム障害を起こす可能性が非常に高いだろう。

 

このように、システムの都合やパフォーマンスの問題など関係なく法的な理由により物理削除しておいたほうが良い。いや、そうして置かなければならない。即時削除が難しい場合、先のように一定期間毎に削除とそれに必要な処理をバッチで回しておくのがいいだろう。

先の記事のようにプログラマは「システムの都合」や「仕様」、「パフォーマンス」の事を前提に考えて設計しがちだ。だが世間からはそんな微々たることはどうでもよく、法に基づいて処理できるように、また、利用者保護を前提に設計すべきだ。

 

このような話を見るたびに「プログラマは世間の考えから少しズレている」と実感してしまう。