なんか仕事上で DELETE_FLAG が '1' だと削除済み的な仕組みのシステムに関わっている。
このシステムで、ある時点にデータを有効にしたり無効にしたりするには、実際にその時間に DB を書き換えなきゃいけない。
個人的には時限爆弾式に設計しておけばいいのにと思う。
以下、擬似言語での例
// 時限爆弾式のデータを持つテーブル table time-bombs { id : integer // DB 内で一意な値にできればいいけど、テーブル内で一意な値で妥協するのが現実的か o-lock-ver : integer // 楽観ロックの為のヴァージョン // このテーブルのその他のデータ started-at : timestamp // 有効期限開始日時 expired-at : nullable<timestamp> // 有効期限終了日時 created-at : timestamp // レコードの作成日時 created-by : typeof(accounts::id) // レコードの作成者 updated-at : timestamp // レコードの更新日時 updated-by : typeof(accounts::id) // レコードの更新者 } // システムのユーザーのアカウントを管理するテーブル table accounts { id : integer name : string // このテーブルのその他のデータ o-lock-ver : integer started-at : timestamp expired-at : nullable<timestamp> created-at : timestamp created-by : typeof(accounts::id) updated-at : timestamp updated-by : typeof(accounts::id) }
こんな感じで有効期限の開始日と終了日を入れておいて、削除フラグを見る代わりに時刻が有効期限内かどうかをみるようにすれば、予め DB にデータをつっこんでおいて、何もせずに指定時間になったら有効になったり、無効になったりさせられると思う。
尚、アカウントの方は同システムで作成者と更新者のフィールドが VARCHAR2 だったので、それは別のテーブルのレコードへの参照にするべきなんじゃないかと思った為。
ま、テーブルの生のデータを見るには文字列の方が見やすいんだろうけど、それって自動化の放棄(人力メンテ前提)な気がするし。