前回の店番だからってそれが数字だとは限らないわけで・・・の続きです。

前回もそれなりに理由を書いたことは書いたのですがまだあったので

例えば以下のような状況
・店番は店舗を一意に識別する
・数字5桁で表される
・DBに格納する際は数値型とする
・帳票や画面に表示する際はゼロパディングする
・画面での入力チェックは型及び数値の範囲のみとする※1
とこんな感じであった場合に

1. ユーザーは更新系の画面で店番を入力し更新対象を選択する。
　　その際ユーザーは[12345]と入力したかったが誤って[1234]と入力してしまう。
2. 画面アプリケーションは入力された値を元にデータを更新する
　　[12345]に対しかけたかった更新は[1234]にかかってしまう。

上記の例では単純に入力チェックを5桁入力にしてしまえば防げますが※2厄介なのはバッチ等です。
例えばある条件に該当する店番をキーにして更新をかけるバッチ等はその店番が正当かどうかを型と値の範囲以外で判定できません。
仮に[12345]と登録したかったレコードを誤って[1234]で登録した場合でもバッチプログラムはそれを誤って入力されたレコードかどうかを判定することが出来ません。

画面の場合の入力チェックについてはさほどコストを掛けずに対処できますが、
それでも設計、製造、テストに掛かる工数は最初から文字列型でエンティティを設計した場合よりも多く掛かると思います。

更にバッチの場合にいたってはデータが入力されてしまった場合、それがたとえ誤っていたとしてもそれを判断するすべがありません。
この状態でそのデータが誤っていることに気づくまでシステムが稼動していたらと思うと非常に危険です。

今回述べた例は以下の様にすれば防げると思います。
・店番は文字列型で格納し常に全桁入力されている
・画面などで入力する場合は全桁入力を求める（'0'についても入力を求める）
・アプリケーション側でゼロパディングなどは行わない（不用意にゼロパディングするとバグを生む可能性がある）
・バッチでは店番が全桁（この例では5桁）でなければ全てエラーにする

とつらつらと書きましたが本来文字列型にすべきデータを数値にすると今回書いたようなバグなどがおきますのでなるべく文字列型で作って欲しいものです。

※1 この1行がなければ実は画面に関する話はいらなかったり・・・
※2 ゼロ埋めで入力を求めます、言うまでもなくアプリケーション側で補完してはダメです