SQLのDELETE文は、INSERTやUPDATEに匹敵するほどの基本的な構文で、SQLを勉強する上でも比較的はじめに習う構文の一つ。
しかしこのDELETE文、実業務ではそこまで使用しません。DELETE文を発行してデータを消すのではなく、履歴データとして残しておくことがシステム構築の定石です。
貴重なデータを消してはいけない
まず業務系システムにとって、データは貴重な資源です。「業務系システム開発とは何をするのか?基本の処理をご説明」の記事でもご説明しておりますが、データがなければ何もできないのが業務系システムです。
だから処理を行うために必要な、また処理履歴を確認するために必要なデータを自ら消してしまうのは、非常に軽率でお粗末な行為なのです。
例えばフィットネスクラブの会員データがあったとして、会員を退会したと同時に会員データも削除したとします。そうすると、もし過去の会員登録データを参照したいときには参照できませんし、過去の会員データを利用して月間の加入者数の推移などの集計をしたい場合、消してしまったデータは考慮されなくなってしまいます。
もし会員が退会したとしても、DELETE文を発行してデータそのものを消去せずに、データは残しておくのがシステム構築のセオリーです。その残しておいたデータを現在進行形で会員になっているデータと区別するためにはどうするのか? という対策は次の通り。
履歴テーブルや削除フラグで対応しよう
削除対象となったデータはDELETE文で物理的に削除してしまうのではなく、履歴テーブルや削除フラグを利用して対応します。
先の例で言うならば、会員の退会処理時に、データを「会員テーブル」から「会員履歴テーブル」に移動させることで、会員テーブルには現会員しか残りません。そして過去のデータを参照したときには会員履歴テーブルも含めてデータ検索すればよいでしょう。
また「会員テーブル」に削除フラグという項目を用意しておき、退会した会員は削除フラグに1を立てるという方法も有効です。もし現会員をSELECTする際には「削除フラグ = 0」という条件を付け加えるだけで済みます。項目名は削除フラグでも有効フラグでも結構ですが、とにかくフラグを立てて管理するのがポイントです。
DELETE文を使用するとき
システムを構築する中で、DELETE文を使用する機会が全くないわけでもありません。それはどういった場合かと言うと、一時データを取り扱う場合です。
帳票発行時やCSVデータ出力時などのアプトプット処理では、出力前の一時的なデータをテーブルに用意しておくことがあります。例えば会員の一覧データを帳票で発行するなら「会員一覧出力用」というテーブルに、帳票発行用のデータを一時的に用意しておき、そのデータを使用して帳票に印字を行います。
次に帳票データを発行する際には、前回使用した一時データは不要なので、「DELETE FROM 会員一覧出力用」というDELETE文を発行し、一時テーブルをクリアしてから、新たに必要となるデータを格納していきます。
おわりに
これまでご説明してきたように、業務系システムにとってデータはシステムを動かす上でなくてはならないものであり、そのデータを消去してしまうことは通常ありえません。
実務となると履歴テーブルへの移動やフラグ管理を行うことで、有効データと無効データの判別をしていくものです。むやみにDELETE文を使わないということを覚えておきましょう。
【株式会社キーシステム】
株式会社キーシステムは、AI活用やスマートフォンアプリ、XR領域の開発において先端IT技術を駆使するテック企業です。最新の技術トレンドに迅速に対応し、SaaS系アプリの開発から業務システムまで、クライアントワークおよび自社アプリケーションの開発を行っています。
開発のお問い合わせはこちらから! 気兼ねなくご相談ください(*´∇`*)