また久しぶりにデータベースの話をしたいと思います。前回は「論理削除か物理削除か」というテーマで記事を書いたらそこそこ反響がありました。こういったテーマは実際にDB設計に関わっている方でないと刺さらないのだと思いますが、そのうち入門者向けの話題も提供したいと考えています。
IDの採番方式
さて本題ですが、今回はIDの採番において私が実際に遭遇したトラブルについての話です。そもそも採番という言葉が一般的ではないのかなと思っていますが。というのも普通にPCで「さいばん」と打っても変換されないので、新しい現場へ行ってPCが貸与されると大抵この単語を辞書登録するからです。英語で言うと numbering が近いのでしょうか。別の言い方をすると発番あるいは番号の払出しといったところでしょうか。
利用するDBMS製品によってはIDの列に自動採番の属性を付与することで済ませるケースもありますが、多少癖もあるので緻密な運用を行いたい場合は自前で実装することになります。実装と言ってもそんなに難しいことはなく、IDが連番であることを利用してその最大値に1を足したものを新しいIDとするだけなのですが、その方式によっては注意が必要です。
これは設計者の好みの問題もあるのですが、テーブルの行数を見積もった時に、まあ普通に取り扱える規模であれば毎回最大値を計算して1を加算しても大した負荷にならないので私はその方式を良く使っています。一方で最大値を計算するのが負荷となるほどの行数が見込まれる場合は、本テーブルの他に最大値を管理する採番用テーブルを作ってそこで管理するケースがあります。
ちぐはぐなロジック
ある現場でデータの移行を実施した時のことです。ファイルに用意したデータ件数と、実際に取り込まれたデータの件数が1件だけ異なるという事故が起きました。あまり細かい話をしてもしょうがないのでざっくり書くと、そのシステムはWEBアプリケーションで、移行はバッチアプリケーションでしたが、両社でIDの採番方式が異なっていたためにWEBアプリで作られたデータを1件バッチで上書きしてしまっていたということが判明しました。
具体的には、WEB側では、採番用テーブルのIDに1足した番号を新しいIDとして本テーブルのレコードを作成し、その番号で採番用テーブルのIDを更新していたのですが、一方のバッチ側では、採番用テーブルのIDを使って本テーブルのレコードを作成し、そのID＋1の番号で採番用テーブルのIDを更新していたのです。つまり採番用テーブルの番号が「使っている値の最大」なのか「次に使うべき値」なのかという解釈において相違があったわけです。
例えば、WEB側でIDが1～5までのデータが作成されていたとします。そこへ移行バッチでデータを追加すると本当は次のレコードのIDは6番でなければいけないのですが、採番用テーブルのIDが5番であるために追加するレコードのIDを5番としてしまい、すると結果的に既にある5番のデータが上書きされてしまうという事象が発生してしまいました。
鍵はコミュニケーション
この話の留意点は、どっちの方式が正しいかという議論ではないというところです。よくありがちなコミュニケーション不足、検討不足の症例です。要はどちらかのやり方にもう一方が合わせていれば全く問題の無かった話です。
また、これが実際に起こった時には、移行の作業等に起因してもっと状況がややこしく、原因を突き止めるのに苦労したのですが、その移行作業の問題点というのは本題を外れるので、いずれ機会があれば書きたいと思います。データベースの話と言いながらマネジメントの話っぽくなってしまいましたね。
