前回からですが、「番号・コード」シリーズに突入しています。
「毎週、何を書こうかと大変でしょう」と言われることが多いのですが、さすがに150回を超えている理由は、「悩まず書く」、これに尽きます。
ひょっとしたら何度か同じことを書いているかもしれませんが、きっとそれは、特別重要なことか、杉山がボケているかのどちらかなのでお許し下さい。
飲むと忘却度が各段に上がる杉山ですが、このメルマガを書いているときは常に素面（しらふ）です。
さて、今回は「伝票番号」もしくは「連番」といったものについて考えてみたいと思います。
データベースには「IDENTITY」という自動連番機能もありますが、これを実際に使うことはあまり無いのではと、私の経験から思います。
「ワークテーブル」と呼んでいる、何か処理する度に削除して作り直すというタイプのテーブルでは使うべきだと思うのですが、マスタやジャーナルといった、何年にも渡って存在するテーブルの項目に使うのは、開発テスト時や保守の事などを考えると、あまりお勧めできません。
伝票番号を画面から手入力するという場合はもちろん、システム機能として伝票番号を付加する必要はありません。
画面から手入力する場合というのは、番号がプレプリントされた伝票を使う場合ですね。
例えば、宅配の伝票番号や、チェーンストア統一伝票番号などです。
もちろん自社伝票を使って先にナンバリングしてあるところもあります。
一般には、伝票番号は自動でシステムから付ける場合が多いのではないでしょうか。
また、「伝票番号」というような運用の形態が無いとしても、入力した画面の登録処理ごとに連番を付けるのは常でしょう。
連番の取得方法として、だいたい以下の2つの処理に分けられます。
1) 売上伝票であれば、売上伝票ジャーナルの伝票番号の最大値をもってきて、それに1を加えて番号を獲得する
2) 伝票番号テーブルといったものを作っておいて、最終番号はテーブルに更新されているので、その番号に1を加えてから番号を獲得する
これら2つのうち、小さなシステムでデータも大容量でない場合は1)でも良いのですが、私は常に、2)を採用します。
これに関して言うと、1)を使っていたシステムではレスポンスに関する問題が起きることがあるのですが、2)で問題が起きるのは、排他処理の問題くらいです。
もちろん、SEとプログラマがどのようにリスクを考えるかで変わってきます。
データベースや言語といった開発環境のクセ、組み方、お客さまの運用を理解して吟味している場合には、どちらでも良いのかもしれません。
ただ、2)を選択していたことでラッキーだったことはいくつかあります。
例えば、現状で「357688番」まで番号が進んでいるシステムを新システムに移行する場合、新システム番号は、「1000001番」から採番するといったことが簡単に実現できます。
この場合、新システムで新規に登録した伝票と移行された伝票とが、一目で確認できるといったメリットがあります。
また、この伝票番号取得の部分は、各エントリでそれぞれコーディングされるのではなく、ストアドプロシージャとして共通に用意され、使われることが望ましいでしょう。
「頭に年度を付けた伝票番号」といった場合も同様に、伝票番号テーブルの主キーに年度を含むだけで同じ処理を行います。
Vol.00158