サロゲートキーが好きで、私の設計物にはサロゲートキーが多いです。RDBの外部キー制約を適用できません。チェックルーチンをアプリかストアードかどちらかに実装することになります。
「項目が増えるし、チェック処理を実装する手間は増えるし、良いことがない」と突っ込まれることもあります。
でも、永久連番を主キーにすると、何かと便利です。コードの付け替えも主キーでないので、比較的容易です。
親伝票・子伝票のリレーションも確立した後は変わることがマズないので、処理が楽。
ログとの突き合わせも楽。
でも、開発ツールで貼り絵感覚で作成している現場(RDBの外部キー制約を自動登録する仕組み)からの、サロゲート邪魔者扱いは年々強まっている希ガス。
屈する日も近いかもしれません。
永久連番項目を number(10) としているシステムがあります。
次のような突っ込みがありました。
「連番が 9,999,999,999 を越えたらシステムが破綻する。」「確実に破綻するような設計は、手抜きだ」
毎日 100件の売上があり、1売上に対して明細がMax20行あるとして、消費する番号は 100* 20 /1日=> 100* 20 * 365 /年 =730000/年
100年稼働しても、73000000レコード= 8桁
全て赤黒処理が発生したとしても * 3 で 9桁。=>充分対応できます。
物理的な桁不足問題と実稼働上の桁不足問題を区別して、対応の可否を考慮したいものです。
年をyyyyで表記してますが、10000年になったときの心配はしません。(以前言及した時のコメントのように、2038年問題などの問題がありますが)
現行のシステムが100年も継続するはずは無いと暗黙に思っているからでしょう。
(2000年問題の根底も類似で、20年以上存命したプログラムが多かったです。100年は有り得るかも。1000年は無理でしょうし、こちらも鬼籍入りしてるし)
それなのに、永久連番のほうは、100年で9桁以下の消耗なのに 10桁の桁溢れを現実問題として捉え、消極的になったり、15桁とかDB制約の最大桁にせよとか言われます。
100年先は、あり得ないと考えるが、2桁先は有り得ると感じるのは、なんだろう。論理性と感覚性をどちらを優先にするかの問題なのかなぁ。
「0.1%でも起こりえるケースは考慮すべし」とするか「1%しか発生しない事象はエラーとして扱え」とするかは、
アプリの性質と予算で決める事です。
桁不足突っ込み回避で全ての数字桁は最大桁(38桁)で取るというのも、有りかもしれませんね。
そうしても機器性能が上がっているので、実質の負荷は少なく満足に稼働しそうなので怖い。
項目桁の検討が荒っぽくなりそう。