採番という単語の話がありましたが、悩まされる事が時々あります。
昇順に順次番号を振っていくのですが採番ですが、伝票番号などは採番で確定する事が多いと思います。
OracleのSequenceで簡単に済ませていたら、大きく手戻りしたことがあります。Sequenceの性格上、ロールバックができません。ロールバックが発生すると欠番が生じたりしまする。
システム的には欠番があっても支障はないのですが、業務の管理面からみると欠番があると不安感を与えるようです。なぜ番号が歯抜けなんだ。と追求されたり、疑り深い人から[不正が在るんじゃないか]と要らぬ嫌疑がかかったりします。月報などで一覧表を作った際も見た目が不細工だったりします。
欠番を無くすことは面倒なことを伴います。伝票データの登録コミット後に連番を取得し伝票番号を更新するのが単純なのですが、それだと伝票番号を主キーに出来ませんし登録以前には番号が不明です。
登録前に番号を確定したい業務要件で且つ欠番はダメという要件があったりします。商談開始時点で、売上表の外枠を作り後にデータを入力していく使用形態もあります。この場合は、伝票破棄などが生じないようにルール化が必要です。実売上げに直結しないケースも出てきます。商談がキャンセルされたり、テスト動作確認で伝票を作ったり等々。
物理削除や論理削除の扱いをなくして、伝票の生死項目を設置し、生きデータ、キャンセルデータ、テスト売上データ、テスト売上赤伝データ等を識別可能にし、非実売上げ伝票番号の追跡を可能にしたりしました。
シーケンスがロールバック可能であったとしても、このケースには適用できないので、設計と運用の問題になります。
業務によりますが、連番も年間通し採番であったり、月採番であったり、部署採番であったりするので、主キーとして設計すると危険が多いので、私は伝票類はサロゲートキーで永久連番を振ります。外には見せませんので欠番が生じても突っ込まれません。業務的には別項目で採番項目を設けて、要望を充たすように設計します。
そこまでしても、完璧にはならなくて、プロジェクトの度に「採番の仕組みはどうしましょう」会議は長引きます。たかが採番されど採番です。