バーコードのデータベース設計

バーコードの値をシステムで扱うとき、生成そのものよりデータの持ち方で問題が起きます。ここでは実装時に繰り返し発生する落とし穴を整理します。

1. 桁数を正規化する

最大の問題が桁数の混在です。同じ商品が複数の桁数で表現されます。

スキャナーの設定によって、同じ商品が8桁で送られたり12桁で送られたりします。データベース側では14桁に左ゼロ埋めして正規化するのが実務上の定石です。

UPC-A   036000291452  → 00036000291452
EAN-13  4901234567894 → 04901234567894
ITF-14  14901234567891 → 14901234567891

これで比較・結合・重複判定がすべて同一のキーで行えます。表示するときだけ元の桁数に戻します。

UPC-Eは8桁ですが、GTIN-8とは別物です。UPC-Eは12桁UPC-Aのゼロ抑制表現で、展開しないと正しいGTINになりません。桁数だけで判定すると取り違えます。スキャナー側で12桁に展開して送出する設定が安全です。

GTINは数値ではなく文字列です。数値型で保持すると先頭のゼロが消えます。

データベース——INT/BIGINTではなくCHAR/VARCHARを使う
Excel・スプレッドシート——セル書式を「文字列」にする。数値のままだと0012345が12345になり、13桁は4.90123E+12と指数表記になります
CSV——インポート時の型推論に注意。多くのツールが数値と判定します
JSON——数値リテラルではなく文字列で持つ

先頭ゼロが消えたGTINはチェックデジット検証に通らず、原因の特定に時間がかかります。

チェックデジットは計算で導けますが、保存する値には含めてください。除いて保存すると、外部システムとの受け渡しのたびに再計算が必要になり、計算方法の取り違えによるバグが入ります。

形式ごとに重み付けの開始が異なる点に注意してください。EAN-13は左から1・3・1・3、EAN-8とUPC-Aは3・1・3・1です。同じ関数で処理すると誤った値になります。

スキャナーやCSVから受け取る値には、しばしば余計な文字が混入します。

保存前に正規化処理を通し、何を除去したかをログに残すと、後の調査が容易になります。

バーコードの値をURLパラメータに含めると、アクセスログ、リファラ、CDNのキャッシュ、ブラウザ履歴に商品コードが残ります。社外秘のコードを扱う場合はPOSTを使うか、ブラウザ内で生成する方式を検討してください。