削除フラグ論議

何の脈絡もなく、思い出したネタです。
でも、「a poor SE」本来のネタに戻ってきました。
コンピュータシステムで扱うデータについて、対象のデータを完全に消去してしまうのではなく、「これは削除したものである」ということを示す印をつける場合があります。そのとき、データにつける印のことを、「削除フラグ」「削除マーク」などと呼んでいました。
「削除」ではなく「無効」にしただけなら、「無効フラグ」とかの方が適切な名称です。特に、後で復活する予定がある場合。
でも、私が経験した仕事では、みんな「削除フラグ」と呼んでいた気がします。
ちなみに、削除フラグを削除状態に更新する処理を「論理削除」、実際にデータを消去してしまう処理を「物理削除」と称していました。


とあるシステムの開発で、データベースの全テーブルに削除フラグを設けるという共通仕様で、進めていました。データベースの基本設計と共通仕様は、私が担当しています。
あるとき、このシステムの開発担当者を統括する副部長クラスの先輩SEと、削除フラグの必要性について議論した事があります。既に開発も進んでいたので、設計を覆す様な議論ではなく、一般論としての議論です。アルコールのある場での議論だったので、熱い議論となりました。
先方の主張は、開発する側の立場として、以下の様なものでした。
・検索条件に常に削除フラグを加える必要があり、SQLが複雑になる。その結果、ミスも多くなる。
・削除処理が、DELETEではなく、削除フラグを更新するUPDATEとなるため、直感的でない。
・原則として、その場で直ちに物理削除してしまって良いのではないか。別途、物理削除をする処理を開発するのは、負担となる。
開発を統括する立場であれば、もっともな理論です。
でも、私の場合、実際の運用も考慮し、削除フラグは有効であると主張しました。
・物理削除は、更新処理よりも負荷のかかる処理である。オンラインサービス中には物理削除をせず、夜間や休日の処理でまとめて物理削除した方が、システム全体のパフォーマンスが良くなる。(当時使用していたDBMSはORACLE8)
・「削除した事」を後で知るには、削除フラグが最も簡単な手段である。アプリケーションで、更新ログを残す様な処理の方が大変だし、DBMSの更新ログでは、必要な情報が得られない場合がある。
・システム利用者が誤って削除してしまったデータを復旧する必要がある場合、削除フラグが設定してあれば、素早く対応できる。
削除フラグの有効性は理解してもらった上で、「システム利用者が誤って削除してしまったデータ」について、次の様な反対意見がありました。
・誤って削除したのであれば、システム利用者が責任をもって再登録すれば良い。利用者のミスを救うために、システムを必要以上に複雑してはいけない。
この先輩SEも、長年社内のシステムの運用に関わってきた人なので、その経験を考慮した上での意見です。実際、誤って削除してしまった件数が少なければ、これで十分なのでしょう。利用者が操作する機能で、複数のデータをまとめて削除できるものを用意しているシステムは、当時はなかった様ですし。
ただしこの場合、登録するデータはシステム利用者が確実に復元できるという前提条件が必要です。運用ルールとして、システムに登録するデータの原票を保管しておく様にしなければいけません。もし、原票がなくても、業務上の他の情報を元に再登録できれば問題ないですが、その点についても議論になりました。先輩SEの主張は、「システム利用者が登録する様なデータで、復元の出来ないものは無い。」ということです。
確かに、それまでのシステムではそうかもしれませんが、私の方からは、土俵を広げてさらに反論。
・システムに画像情報を登録する様な場合、例えば、人の顔の表情や、自然の風景など、全く同じものが再現できないケースはある。今後、その様な画像情報を扱うシステムが出てくる可能性がある。
この議論が行われたのは、2000年の冬ごろ。人事のシステムでも、顔写真をシステムに登録している事例は身近にはありませんでした。それに、人事システム用の顔写真なら、同じ表情である必要はありませんし、登録原票としてシステムの外に画像データを保存しておく事も、今時のディスク容量なら容易です。
今考えると、復元可能性の議論の辺りから、アルコールがまわっていたのでしょう。かなり、熱く語った覚えがあります。
この議論の舞台になったシステムは、その後、私自身が運用を担当する事になりました。
先輩SEの主張通り、削除フラグを検索条件に入れ忘れたミスによるトラブルもいくつかありました。でも、これは、プログラム単体の検査を十分に行えば、防げる問題です。
一方で、削除フラグを更新するときに、同時に日時/ユーザID/プログラムIDを正しく記録しているプログラムが多かったので、いつどうやって削除されたかを知るための情報として、役立ちました。物理削除をしてしまったのでは、もともと存在していたかどうかもわかりません。
結果として、多少開発に負担があっても、削除フラグは有効であったと、思っています。

“削除フラグ論議” への 3 件のフィードバック

  1. ワタシも「削除フラグ」、「論理削除」、「物理削除」と呼んでます。
    言われて気付いたのですが、「無効フラグ」のが表現が的確ですね(^_^;)
    「削除フラグ」を使用するか否かはシステムの重要度というか、
    データの重要度に依存すると思うので、一概に是非は問えないと思います。
    後は設計思想でしょうか。
    利点や欠点は今回の記事に出ているとおりだと思うので、そこらへんを理解して使うべきでしょうね。
    闇雲に「削除フラグ万歳」みたいなDBありますもん・・・。

  2. コメントありがとうございます。
    たしかに、システムの規模とか重要度とか用途とかに依りますね。話題にしたシステムは、大規模な基幹業務システムです。
    さて、この議論をしていた時も、この記事を書く時も、「誤って削除したデータはバックアップから復元する」という発想が抜けていたようです。バックアップに関しても、ネタがあるので、またいずれ。

  3. プロトタイプでつまずいて…(1)

    先月の初めからやっている求人マッチングサイトの制作は、引き続き基本設計を進めており、並行して技術的な課題等に取り組んでいます。 大企業の人員削減のニュースを耳にする度に、早く完成させねばと思っているのですが、1人で他の業務の合間にやっているので、なかなか進..

コメントは受け付けていません。