データベース構造における数値の桁合わせの目的について

Question

前提

データベース構築する上でのID等の桁合わせについて質問です。

例えば顧客を管理するとなったときに
支店コード＋支店ごとの顧客番号
上記の組み合わせで顧客を識別することがあるかと思います。

このとき、支店コードの桁数を揃えることで
支店コード＋顧客番号の組み合わせの重複を避けることが
桁合わせの目的と認識しています。

例)
支店コード1：東京＋顧客番号11＝111→支店コード01＋顧客番号11＝0111
支店コード11：大阪＋顧客番号１=111→支店コード11＋顧客番号1＝111

この事例の顧客番号についてですがこの数値の桁を
揃える必要性についてお聞きしたいです。

お聞きしたいこと

末尾のコードかつ桁数が増える可能性がある数値に対して
桁を揃えることは不要なのではないかと思っているのですが
知見が狭いのでどのような懸念点があるのかわかりません。
（のちのち、識別コードが支店コード＋顧客番号＋性別コード
このように改訂される場合を想定するくらいしか思いあたりません)

基礎的な質問かと思いますが
桁揃えと検索しても揃える方法は沢山で出てくるのですが
要不要の事由の調べがつきませんでした。
上記以外の理由や目的等あれば教えて頂きたいです。

Comments

[dameo]

自分で決められる立場だということでしょうか？
それとも最大長は決まっているけど、それをどう設計・実装するかで迷いがあるということでしょうか？

[ukana]

漠然とした質問・また情報が足りておらず申し訳ありません。

前提としては自分で仕様は決められる立場です。最大長も決まってはいません。

1度決めた識別コードを変更しない＝保守が容易であることを重視して
桁揃えせずに数値を使いたいと思っていたのですが
どのような不都合があるのかが分からず、質問しました。

[dameo]

何を良しとするかというのは現場によって割と違うと思います。業界標準で何かコードがある場合(JANコードや銀行コードや支店コードなど)は長さが変わるということはよほどのことがなければないのですが、システム要件を決める会社の都合で変更可能な部分は何のかんの変更が入るわけです。変更が入るからといって汎用な設計(例えばIDを連番とし、内部ID→表示IDのような冗長な設計)にすると、分かりにくくて不具合が多くなったり、パフォーマンスが悪かったり、容量を食ってしまったりするかもしれません。逆に見た目が分かりやすい設計にするとすぐにDDLが変わって、都度全体の実装を変更しないといけなくなり、変更の度にコストがかさんでしまうかもしれません。

例えば既存システムが他にあるような状況なら、そちらに合わせた方が良いでしょう。中途半端に変えると面倒なことになるので(何らかの計画で移行する段取りになってればOK)。既存システムもなく、スクラッチから作れるのなら、好きなように作ればいいのですが、ちゃんとルールを決めて統一しておきましょう。

[ukana]

とても丁寧な説明ありがとうございました。
具体的な例を挙げて頂きイメージすることができました。

既存のシステムも使いつつ、新しくデータベースを作るケースが多いので
アドバイスを頂いたようにあまり逸脱した仕様にしないようにすること、
メリット・デメリットを天秤にかけて仕様を考えていきたいと思います。
ありがとうございました。

Answer 1

システムの要件によりますね。
「顧客番号は10桁の数値」と決まっていたらひと目で顧客番号と分かりやすい気もしますが。

何も縛りがないなら桁揃えは不要なんじゃないでしょうか。