SQLのDELETE文は、INSERTやUPDATEに匹敵するほどの基本的な構文で、SQLを勉強する上でも比較的はじめに習う構文の一つ。

しかしこのDELETE文、実業務ではそこまで使用しません。DELETE文を発行してデータを消すのではなく、履歴データとして残しておくことがシステム構築の定石です。

貴重なデータを消してはいけない

まず業務系システムにとって、データは貴重な資源です。「業務系システム開発とは何をするのか?基本の処理をご説明」の記事でもご説明しておりますが、データがなければ何もできないのが業務系システムです。

だから処理を行うために必要な、また処理履歴を確認するために必要なデータを自ら消してしまうのは、非常に軽率でお粗末な行為なのです。

例えばフィットネスクラブの会員データがあったとして、会員を退会したと同時に会員データも削除したとします。そうすると、もし過去の会員登録データを参照したいときには参照できませんし、過去の会員データを利用して月間の加入者数の推移などの集計をしたい場合、消してしまったデータは考慮されなくなってしまいます。

もし会員が退会したとしても、DELETE文を発行してデータそのものを消去せずに、データは残しておくのがシステム構築のセオリーです。その残しておいたデータを現在進行形で会員になっているデータと区別するためにはどうするのか? という対策は次の通り。

履歴テーブルや削除フラグで対応しよう

削除対象となったデータはDELETE文で物理的に削除してしまうのではなく、履歴テーブルや削除フラグを利用して対応します。

先の例で言うならば、会員の退会処理時に、データを「会員テーブル」から「会員履歴テーブル」に移動させることで、会員テーブルには現会員しか残りません。そして過去のデータを参照したときには会員履歴テーブルも含めてデータ検索すればよいでしょう。

また「会員テーブル」に削除フラグという項目を用意しておき、退会した会員は削除フラグに1を立てるという方法も有効です。もし現会員をSELECTする際には「削除フラグ = 0」という条件を付け加えるだけで済みます。項目名は削除フラグでも有効フラグでも結構ですが、とにかくフラグを立てて管理するのがポイントです。

DELETE文を使用するとき

システムを構築する中で、DELETE文を使用する機会が全くないわけでもありません。それはどういった場合かと言うと、一時データを取り扱う場合です。

帳票発行時やCSVデータ出力時などのアプトプット処理では、出力前の一時的なデータをテーブルに用意しておくことがあります。例えば会員の一覧データを帳票で発行するなら「会員一覧出力用」というテーブルに、帳票発行用のデータを一時的に用意しておき、そのデータを使用して帳票に印字を行います。

次に帳票データを発行する際には、前回使用した一時データは不要なので、「DELETE FROM 会員一覧出力用」というDELETE文を発行し、一時テーブルをクリアしてから、新たに必要となるデータを格納していきます。

 

おわりに

これまでご説明してきたように、業務系システムにとってデータはシステムを動かす上でなくてはならないものであり、そのデータを消去してしまうことは通常ありえません。

実務となると履歴テーブルへの移動やフラグ管理を行うことで、有効データと無効データの判別をしていくものです。むやみにDELETE文を使わないということを覚えておきましょう。

 



【X(旧twitter)でも情報発信中】

Xを最近始めたので、フォローしてもらえると嬉しいです(エンジニア界隈の方はフォローバックさせていただきます)! システム開発に関することや、最新テクノロジーのことなど、世のエンジニアにとって有用な情報を発信してます!

"X" @TECH_KEYSYS