伝票モデルとサロゲートキーと複合キーとちょくちょくBurix

最近とあるBurix中毒患者仲間と、ちまたで話題のサロゲートキー(個人的にはIDでいいじゃんって思うので以後ID)と複合キーの話をしてて、そんなの未だに話題になるネタだったんだ・・・って思いつつふとタイトルが思い浮かんだから・・・
伝票モデルではIDと複合キーの問題は奇麗にクリアしてました。というのは両方の良いところが奇麗な形で盛り込まれているから。
ちまたで話題の・・・複合主キーを避けるべき理由 - 虎塚

伝票モデルでは関連の考え方そのものがERモデルベースの物と全く違っていて、伝票一つに他の伝票とどう紐づいているのかを基準に項目を分類するだけです。
伝票モデルでは全ての関連をこんな風に分類します。というか、これ以外は伝票の中に無い
Field,AquisitionField,ParentField,LookupMany,LookupSingle,ChildMany,ChildSingle
＃それぞれに色々あるんだけど、詳しくは省略。
今回の説明で(というか伝票モデルの中でも)最も重要なのはAquisitionField（スペルあってるかな・・・以後aqField）。
aqFieldは別の伝票の任意の項目をあたかも自分の伝票の項目の様に扱える項目って事です。
簡単に言えば、請求伝票での請求先は全てaqFieldになるわけですね。
ちなみに、別の伝票にあるaqFieldなども含めてaqFieldで指定可能だったりします

ここからBurix(今のところ世界でただ一つの伝票モデルの実装)の話
Burixでは各DenpyoにはDenpyoIdというIDを自動で割り当ててました。いわゆる主キーはこれ。
ここで重要なのは伝票モデルはプログラマも伝票を扱える様にするというのが重要なので、当然、DenpyoIdを意識しない事も可能な訳で、その為に業務上必要な項目を選んでユニークキーをつけれるんですが、このユニークキーはaqFiledの項目も指定可能。
とすると、ナチュラルキーを伝票のユニークキーに指定すれば良い。
ナチュラルキーの長さが変更されたとしても、DenpyoIdは影響を受けないのでSQLは特に問題なく動作可能だし、更にナチュラルキーの値が変わったとしてもそのナチュラルキーは事実上そこにしかないので、特に影響を受ける事はない。
仮に大分類小分類があって、小分類をaqFieldとして指定して大分類も含めてとってきていれば、間に中分類を追加したとしてもaqFieldとしてその項目を取得するという風に定義を書き換えて生成し直せばあとは画面の修正でOK

個人的には伝票モデルを作ってて一番良かったのはaqFieldを思いついた事かな〜イメージはずっと前からあったんだけど、処理の速度を考えると上手い実装が思い浮かばなかった。
それが出来たときには、もう複合主キー問題は無視できるほどちっちゃい話だったし、DBの扱い方自体が違う世界に突入してた。
まぁそんな感じで世界で数えるほどしか居ない伝票モデル＆Burix中毒患者は普通のテーブル設計を見ながら可哀想な日常を送ってる訳です。