子豚のココのお勧め商品　joyeux cochonnet

論理削除 Casual Talks #1

なにやら、「論理削除 Casual Talks #1」が話題になっているようなので、
この話題に便乗してみました。

事の発端は、2013年01月に発売された、
和田親子(和田省二氏、和田卓人氏)共同監修の書籍『SQLアンチパターン』。

SQLアンチパターン 新品価格 ￥3,456から (2015/9/1 16:50時点)

■内容紹介
本書はDB設計やSQL記述の際に避けるべき事柄を1章で1つ、25個紹介する書籍です。
リレーショナルデータベースを中心に据えたシステム開発には、様々な場面で陥りやすい失敗（アンチパターン）があります。
本書はデータベース論理設計、データベース物理設計、クエリの記述、アプリケーション開発という4つのカテゴリに分かれて、それぞれの分野におけるアンチパターンを紹介し、失敗を避けるためのより良い方法を紹介します。
複数の値を持つ属性や再帰的なツリー構造の格納から、小数値の丸めやNULLの扱いに起因する問題、全文検索やSQLインジェクション、MVCアーキテクチャなど、実践的かつ幅広いトピックを網羅します。
データベースに関わるすべてのエンジニア必携の一冊です。


これまで知らなかったのですが、
どうやら「論理削除」については、データベースを使い倒している
データベーススペシャリストの間では頻繁に議論が交わされているようです。

論理削除は、データベースのレコードを物理削除する代わりに、
削除フラグなどのカラムを利用して、レコードを隠すといった手法です。

なぜこのような手法が必要になるのかというと、
高トラフィックなWEBサイトなどにおいて、
ユーザーの操作に応じてデータ削除を行う場面があります。

その際、物理削除するのではなく、論理削除（削除フラグを立てる）することで、
誤ってデータを削除された場合に簡単に復元ができる、
あるいは、物理削除より処理速度が速いなどのメリットがあるからです。

また、削除自体を記録として残せることにもなるので、
ログデータを別に用意する必要も無くなります。

しかし、その反面デメリットもあります。
ひとつは、削除フラグが必要となるため、
SELECTするときには常にWHERE句によって削除フラグを考慮しなければならなくなります。

また、複数のテーブルが存在する場合、あるテーブルには削除フラグが実装されていて、
別のテーブルには削除フラグが実装されていないことがあると、
後々、そのシステムに精通していない人がカスタマイズなどを行う際に、
トラブルを生じる可能性が高くなります。

また、削除フラグが立っている大量のデータが残ります。

ということで、
これらのメリット／デメリットを前提にして、
論理削除が正しいものなのかどうかですね。

わたし個人の経験からすると、
削除フラグというカラムを用いることがアンチパターン。

ここで明確にしておきたいのが、
ユーザーの削除操作も実はデータ更新の一部だということ。

だから、ここは敢えて、更新日のカラムを代用する形で未来の日付を代入する方が便利です。
いわゆるマジックナンバーとしての未来日ですね。

しかし、マジックナンバーは慎重に扱うべきなので、
futuredate = 最大日付と、
一旦変数に割り当てて利用した方がよさそうです。

ちなみに、最大日付は取扱うRDBによって異なります。
SQL Server：9999-12-31 23:59:59
Oracle：9999-12-31 23:59:59
MySQL：9999-12-31 23:59:59
PostgreSQL：5874897-12-31 23:59:59

これは、
9999-12-31 23:59:59が妥当かなと思います。


話を戻しますが、
更新日のカラムを用いた場合、
誰が削除したのかなどの付加情報も別のカラムで記録した方が良いです。



とにかく、秒間１億のトランザクションを捌くのに、物理削除は難しい。
という意見もあるようですが、

論理削除を必要とするのは、どのような場面でしょう。

例えば、WEBサイトを想定した場合、
「ユーザの退会」「商品購入キャンセル」などが思い当たります。

「ユーザの退会」の場合、ユーザーはご自身の氏名、住所、メールアドレスなどの情報を消去して欲しいと思うでしょうし、
なにせ個人情報なので、この場合はデータ削除です。

「商品購入キャンセル」の場合、一度は購入（注文）処理を行っていますので、
これに対しての赤伝処理となるので、データ削除ではなく、キャンセルデータの追加です。

どちらも、論理削除の対象ではなくなります。

ここで、もうひとつ加味しておきたいのは、
個人情報だからといって物理削除してもよいのかという点。

これについては、各サイトのガイドラインを参考にした方がよさそうです。

主要なガイドライン

【はてな情報削除ガイドライン】
・公的機関からの削除要請
　警察、インターネットホットラインセンター、法務省人権擁護局等から違法情報、有害情報、人権侵害情報として削除要請を受けた場合、要請の内容が正当であれば、原則として削除を行う。特に緊急性がある場合には即時削除を行う。
青少年の保護を目的として教育機関からの削除要請を受けた場合、要請の内容が正当であれば、原則として削除を行う。特に緊急性がある場合には即時削除を行う。
選挙運動期間中に投稿された情報に対し、公職選挙法違反に該当するとして、選挙管理委員会から削除要請を受けた場合、要請の内容が正当であれば、原則として削除を行う。特に緊急性がある場合には即時削除を行う。

・利用者が死亡した時の対応
はてなでは、正確に確認できる登録個人情報が限定されているため、利用者が死亡したとして削除等手続きを遺族や近親者が依頼してきた場合も、利用者の死亡や依頼者が遺族や近親者であるという事実を確認することが困難であることがほとんどである。 そのため、情報削除等の依頼を受けた際には下記のような措置を行う。
原則として、利用者のメールアドレスに連絡を行い依頼内容の確認を行う。所定の期間内に返信がない場合には、最低限の表示制限や設定変更等の措置を行う
利用者のメールアドレスから所定の期間内に返信がない場合も、死亡した事実が確認できたとは言えないため、データが物理的に失われる措置は原則として行わない。また、ユーザーアカウントの譲渡や相続は行わない。
登録メールアドレスから返信があった場合には、その意向に従う。
ただし、サービスの利用状況によっては、利用者の死亡や依頼者が遺族や近親者であることが確認できる場合もあるため、個別の事情や状況を考慮の上、最終的な対応を決定する。


【楽天会員規約−個人情報保護方針】
7.保有個人データの確認等について
・ 削除の手続きにつきましては、保有個人データの性質上、削除対応できないことがあります。この場合、当グループは、利用停止およびサービス提供者への提供停止をすることで対応いたします。
・ お客様が利用停止またはサービス提供者への提供停止の手続きをされたときは、サービスの全部または一部の利用ができなくなる場合があります。
・ 当グループは、コンピュータの故障その他不可抗力または人的ミスによるデータ消失に備えてバックアップデータを保管することがあります。このバックアップデータは、その性質上、確認等の手続きを行うことができません。


【amazon アカウントを閉じる】
amazon アカウントを閉じる


各サイトを見る限り、個人情報の利用停止は行っているようですが、
データ削除は行っていないように見えます。

で、ここでもうひとつ関係してくるのが、「個人情報の保護に関する法律」です。
この法律で注目したいのが、25条、26条、27条。

第二十五条
1.個人情報取扱事業者は、本人から、当該本人が識別される保有個人データの開示（当該本人が識別される保有個人データが存在しないときにその旨を知らせることを含む。以下同じ。）を求められたときは、本人に対し、政令で定める方法により、遅滞なく、当該保有個人データを開示しなければならない。ただし、開示することにより次の各号のいずれかに該当する場合は、その全部又は一部を開示しないことができる。
一 　本人又は第三者の生命、身体、財産その他の権利利益を害するおそれがある場合
二 　当該個人情報取扱事業者の業務の適正な実施に著しい支障を及ぼすおそれがある場合
三 　他の法令に違反することとなる場合
2.個人情報取扱事業者は、前項の規定に基づき求められた保有個人データの全部又は一部について開示しない旨の決定をしたときは、本人に対し、遅滞なく、その旨を通知しなければならない。
3.他の法令の規定により、本人に対し第一項本文に規定する方法に相当する方法により当該本人が識別される保有個人データの全部又は一部を開示することとされている場合には、当該全部又は一部の保有個人データについては、同項の規定は、適用しない。
（訂正等）

第二十六条
1.個人情報取扱事業者は、本人から、当該本人が識別される保有個人データの内容が事実でないという理由によって当該保有個人データの内容の訂正、追加又は削除（以下この条において「訂正等」という。）を求められた場合には、その内容の訂正等に関して他の法令の規定により特別の手続が定められている場合を除き、利用目的の達成に必要な範囲内において、遅滞なく必要な調査を行い、その結果に基づき、当該保有個人データの内容の訂正等を行わなければならない。
2.個人情報取扱事業者は、前項の規定に基づき求められた保有個人データの内容の全部若しくは一部について訂正等を行ったとき、又は訂正等を行わない旨の決定をしたときは、本人に対し、遅滞なく、その旨（訂正等を行ったときは、その内容を含む。）を通知しなければならない。
（利用停止等）

第二十七条
1.個人情報取扱事業者は、本人から、当該本人が識別される保有個人データが第十六条の規定に違反して取り扱われているという理由又は第十七条の規定に違反して取得されたものであるという理由によって、当該保有個人データの利用の停止又は消去（以下この条において「利用停止等」という。）を求められた場合であって、その求めに理由があることが判明したときは、違反を是正するために必要な限度で、遅滞なく、当該保有個人データの利用停止等を行わなければならない。ただし、当該保有個人データの利用停止等に多額の費用を要する場合その他の利用停止等を行うことが困難な場合であって、本人の権利利益を保護するため必要なこれに代わるべき措置をとるときは、この限りでない。
2.個人情報取扱事業者は、本人から、当該本人が識別される保有個人データが第二十三条第一項の規定に違反して第三者に提供されているという理由によって、当該保有個人データの第三者への提供の停止を求められた場合であって、その求めに理由があることが判明したときは、遅滞なく、当該保有個人データの第三者への提供を停止しなければならない。ただし、当該保有個人データの第三者への提供の停止に多額の費用を要する場合その他の第三者への提供を停止することが困難な場合であって、本人の権利利益を保護するため必要なこれに代わるべき措置をとるときは、この限りでない。
3.個人情報取扱事業者は、第一項の規定に基づき求められた保有個人データの全部若しくは一部について利用停止等を行ったとき若しくは利用停止等を行わない旨の決定をしたとき、又は前項の規定に基づき求められた保有個人データの全部若しくは一部について第三者への提供を停止したとき若しくは第三者への提供を停止しない旨の決定をしたときは、本人に対し、遅滞なく、その旨を通知しなければならない。


いうなれば、データを削除した後に問題が発覚し、裁判等になった際に必要な証拠がなくなると困ります。
ってことで、「削除」＝「停止」としているわけです。



ますますわからなくなってきました。

システムの規模というより、取扱う個人情報の規模にもよるのでしょうが、
顧客情報の場合、安易に削除することはよくないのかもしれません。


サイトで取扱っている情報の削除というのは、
物理削除の対象ではなく、
さらに、論理削除の対象でもなさそうです。
いわゆる、「停止」ステータスをもつデータ。

こうなってくると、
いつ停止処理を行ったのか？
その際のIPは？などのデータを追加する必要があります。

そうなると、個人情報を記録しているデータは論理削除で、
削除依頼データは追加処理ということになるのかもしれませんね。

あくまで個人的な見解なので、
スキル不足による誤解、ご認識は否めませんので、
その点はご容赦ください。


また、事の発端となった書籍『SQLアンチパターン』。
議論になるほどの良書のようです。

SQLアンチパターン 新品価格 ￥3,456から (2015/9/1 16:50時点)