札幌で行われたPostgreSQL勉強会で@syachi氏により発表された資料です。PostgreSQLの機能を使って削除フラグをうまく運用する方法について解説しています。

データベースで削除フラグを表現する際、is_deletedなどのboolean型カラムを用意するのが普通です。こうすることでデータを削除する際、値をTRUEに変更するのみでデータ自体を削除しないため、何らかの事情でデータを復活させたい場合には便利である一方、アプリケーションコード側で削除コードを判定する条件が散在するデメリットもあります。また、関連性をデータベース側に持たずデータ整合性をアプリケーション側で保証するという設計を採用するため、データが膨れ上がった数年後に管理しづらくなってしまいます。

資料では、PostgreSQLが持つ機能を利用し、削除フラグを使いつつデータに矛盾がないことを保証する方法を示しています。まず、有効なレコードの重複を許可しない方法としてis_deletedカラムを条件にした部分インデックスを作成します。また、親子関係を持つテーブルにて親テーブルの削除フラグを変更した場合に子テーブルまで伝搬しない問題に対しては、削除フラグのカラムを設ける代わりにPRIMARY KEYカラムの値を変化させることで削除判別を行う方法を提示しています。さらに削除フラグの代替案として履歴テーブルを別途用意し、DELETEした際に履歴テーブルにINSERTするTRIGGERを用意する方法を解説しています。

データベースを設計する際、物理削除することを怖がって削除フラグにて論理削除を行うアプローチを安易に採用してしまいがちですが、数年後のデータ管理を見据えた場合、採用するデータベースの特性や機能をよく理解しきちんと設計しておく必要があります。今回の資料は複数の選択肢を提供してくれており、非常に参考になります。

URL：http://www.slideshare.net/syachi/ss-8808413