RDBテーブル上の主キーと業務上のキーは一致させる必要はないので、人工キーが有効になるのですが、今回は、業務上のキーの話。
顧客台帳や商品台帳などのマスターのコード化は、対象のモノを特定するために設定します。
逆に、名称で特定できるのであれば、コード化する必要はありません。
性別を "男","女" , 人格区分を "個","法" で固定値で保持しても、支障がないし、スッキリする場合もあります。
なんでもコード化することに疑問を覚える時があります。
顧客台帳や商品台帳の名称をキーにできないのは同姓同名や、名称変更などがあり、単一のモノと対にならないことも一因です。
ユニーク値を構成できれば、何でもキーになり得るのですが、浅い考えでコードルールを作ると混乱を招きかねません。
閑話休題。不思議な体系のシステムがあるそうな。
顧客コードを6桁に設定しているシステムがあります。
上1桁が "T" は得意先 "S" は仕入先 "@"は得意先兼仕入先
二桁目: 顧客名称の50音表の行数
青木さんなら あ なので 1
香川さんなら か なので 2
三桁目: 顧客名称の50音表の段数
木村さんなら き なので 2
4,5,6桁目
上3桁確定後の連番
その結果、得意先の木村さんは、T22002のようになります。
疑問:
・得意先と仕入先の区別は、客の扱い区分なので、客情報とは別にすべきでしょう。
ある人を得意先で登録していて、そこから仕入れることになったらキーを付け替えることになってしまいます。
「そんなことはあり得ない。仕入先と得意先は厳格に分かれている」というケースでも、キー構成に組み入れるのは疑問です。
・５０音表の段数と行数で数値化する意味が不明。
そのままカタカナを取り入れたら済むのでは。.....これは質問したことがあります。
木村さんなら "ｷ" にすれば、二桁目と三桁目は一つで済みますしね。
主キー項目は文字項目だが、英数字項目になっていて、カタカナは入らない。....というのでなく、システム的な項目にカタカナが入るのは不細工だ。との判断らしい。アヤシイですが。
・社名変更や合併したりしたら、コード体系を変更するのでしょうか?
主キー付け替えを行っているらしいです。
このようになった背景はシステム歴史を聞くと、根拠はあるようです。
もともと得意先しか登録していなくて、キー項目は5桁の数字で管理していたらしい。
仕入先の項目も同じ項目なので、併用しようとしたとき、区別する必要があるという意見を聞いて、主キーの頭を1byte増やして、文字項目にしたらしい。
業務システムは滞りなく動作しているので、業務要件的には満足に動作している....というのですが。
過去の継承という束縛は以外意外に大きく、今までのルールを崩すのはナカナカできないようです。
システム屋は保守的な人が多いと見るか、継承したほうが危険率が少ないと見るか、見解は分かれますが、スクラッチビルドしたほうがスッキリすると思うのです。
#主キーを付け替える。というのは危険を伴う行為なので、極力発生しないようにシステム設計したいものです。