flint>flint blog>2011年> 7月>31日>データの削除

データの削除

戸ノ口堰第二発電所

コンピュータシステムの使用において、データの削除は最も危険な操作の一つ。 実際、「誤って削除してしまったデータをなんとか復元できないか」というユーザからの問い合わせは日常茶飯事です。 特に対象が重要なデータである場合、必死の形相で頼み込んでくるユーザへの対応は、こちらとしてもかなりの精神的重圧を伴うため、あまり何度も経験したいものではありません。

こうした問題への対応策として、ディスク上からデータを削除するのではなく、そのレコードに対して「削除した」というフラグを立てる、という方法があります。 その上で、削除フラグの付いたレコードについて、システムが一切の操作を行わないようにすれば、ユーザからはあたかもそのレコードが削除されたかのように見えるでしょう。 (というか、原理的に区別する方法は存在しません。)

この仕組みを実装するため、私はデータベースを設計する際に、ほぼすべてのテーブルに、"disabled" という名前の INTEGER (整数) 型のフィールドを付けることにしています。 ここで、ある程度ソフトウェア開発の経験がある方は以下のような疑問を持つかもしれません。

  • 名前が「削除 (deleted)」ではなく「無効 (disabled)」なのは何故?
  • 型が BOOLEAN ではなく INTEGER なのは何故?

これは、「削除」という状態を「無効度」という概念に包括して考えるためです。

無効度

少し話題は変わりますが、システムを使っていると、入力したデータを一時的に無効 (非公開) 状態にしておきたくなることがしばしばあります。 (書きかけの文章を取っておいたり、翌日以降にサイトに掲載する予定のコンテンツを予め登録しておく場合などがそうですね。) そのような場合、各レコードに公開状態を表すフィールドを持たせるのが一般的な手法です。

この要件だけを考えると、そのカラムはその名前を "released" などとして、BOOLEAN 型として定義すれば良さそうに思えるかもしれません。

released の値 運用
FALSE (0) 無効
TRUE (1) 有効

しかしながら、この「状態フラグ」と、最初に述べた「削除フラグ」を別々に保持するのは無駄が多いように思えます。 更に、削除されたデータはシステム上の操作の対象とならず、O/Rマッピングなどによって、メモリ上のオブジェクトとして表現されないことも勘案すると、これらのカラムをもっとスマートに定義できることに気がつくでしょう。 即ち、その名前を "disabled" とし、データ型を INTEGER に変更して、以下のように運用すればよいのです。

disabled の値 運用
0 有効
1 無効
2 削除

システムがデータベースからレコードを読み出す際は必ず disabled <> 2 という条件が付くため、この disabled の値をオブジェクトのフィールド値として Boolean 値として表現するには、単純に disabled != 0 という変換を行えばよいのです。

個人的にはとても自然かつ実用的な設計手法であると評価しているのですが、いかがでしょうか。 次回は、これと同じ発想に基づいた、レコードの変更履歴管理のためのデータベース設計手法について紹介したいと思います。 (→ 履歴を取ってみよう)

成田 (「無効度」の英訳は "disability" ではなく、"inability" です。)
このエントリーをはてなブックマークに追加

コメント

投稿者
URI
メールアドレス
表題
本文