2014年11月24日

60. テーブルの論理削除フラグ(カラム)について

テーブルに論理削除フラグ(カラム)は持たないこと。
これまで、テーブルに論理削除フラグを持つことで、破綻してしまった(各機能間の整合性を取ることができなくなった)システムをいくつも身近で見てきたため。

事例)
・主キーをそのままにしていたため、
 論理削除したデータと新規登録するデータとで一意制約違反が発生してしまった。
 (論理削除したデータと新規登録するデータを共存させる場合、最初から 通番(シーケンス値)を含めた複合主キーにする などの対策が必要となる。)
・最初に 論理削除フラグを持つテーブルと持たないテーブルのポリシー を決定できていなかったため、
 後の改修で追加したテーブルに論理削除フラグを含め忘れたため、
 Select文の検索条件に論理削除フラグを含め忘れたため、
 バッチ処理が発行するSelect文の検索条件には 論理削除フラグを含めなくてよい などポリシーを曲げてしまったため、
 論理削除フラグを別の用途(表示フラグなど)でも利用したため、
 表示されるべきでないデータが(UI上に)表示されたり、表示されるべきであるデータが(UI上に)表示されなかったりした。
 また、機能追加や機能改修を行う際、その都度、(その機能での)論理削除フラグの取り扱い方に困惑することになった。
・インデックスに論理削除フラグを含め忘れたため、
 全体的なパフォーマンスダウンにつながった。

確かに、いつでもレコードを復活できるメリットはあるものの、論理削除したデータを保存する専用テーブル、専用ログファイルを設けるなど、満たしたい要件に合わせた代替手段を講ずること。

この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

※ブログオーナーが承認したコメントのみ表示されます。

この記事へのトラックバック