赤黒問題
プリキュアの話題ではありません(←それは白黒)。
先日、システムによってどころかテーブルによって赤黒の作り方がまったく違うということが判明し関係者で集まり話あうことになったのだが、これまた人によって赤黒の考え方が違ったりして面白い。
赤黒と言わずに更新/削除のパターンを思いつく限り列挙してみたが、結構あるなぁ。
- 物理更新・物理削除
- 言わずとしれたUPDATE発行による更新およびDELETE発行による削除。システム系のプログラムだとこれですかね。
- 物理更新・論理削除
- 更新はUPDATEするが、削除は削除フラグによって判断。マスタとか周辺系システムのトランザクションだと一般的。
- 赤黒伝票(論理削除)
- 元の行を論理削除し、新たに黒伝の行を追加。
- 赤黒伝票(打消型)
- 元の行に対し打消しの行(赤)を挿入し、さらに黒伝の行を追加。会計システムだと必須。基幹系のトランザクションだとわりと一般的?
- 赤黒伝票(マイナス型)
- 元の行に対しマイナスの行(赤)を挿入し、さらに黒伝の行を追加。最近の会計システムだとこの形式の伝票も可能(打消型だと貸借の残高が増えるが、マイナス型だと残高が増えないのがメリット)。SUM関数で単純合計できるため便利。
- 赤黒伝票(打消+マイナス型)
- まれにマイナスの黒伝が発生するケースがあるため、情報として両方保持する場合に使う。
- 赤黒伝票+物理/論理更新・削除
- 会計連携するまでは物理あるいは論理で更新・削除を行うが、連携した後は赤伝票を起こすという複合パターン。ちょっとした失敗はリカバーしたい場合に使うが、リアルタイム連携のシステムだと使えない。
個人的な見解としては、業務システムで物理削除は論外だけれど会計システムを除けば物理更新・論理削除もアリかなぁと思っていたりもする(データベースにdiffモードがほしいと思う今日この頃)。
さらに伝票番号を使いまわすか否かによって複合キーの選択をどうするかも考えどころ(この問題の技術的な制約はIDの導入によって劇的に緩和されるわけだが、伝票番号を使いまわし可能にすべきか否かは別の問題なので議論の余地がある)