岩波書店のISBNコード騒動について考える。
Twitterを見ていたらこんなまとめを見つけた。
ISBNコードといえば、すべての本に付けられる世界共通で一意なコード、という印象だった。
だけど、そのISBNコードを使いまわす出版社があると知って、
データベースのプライマリキーとかにISBNコードは使えないなぁと思った。
この問題について自分が思うことを書いていきます。
そもそもISBNコードって何?
世界共通で使われる本につけられるコード。
出版社から刊行されて書店で流通する書籍、CD、カセット等に概ねつけられるもの。ただし雑誌は除く。
日本で管理しているのは日本図書コード管理センター。
詳しくはWiki先生に聞いて。
ISBN - Wikipedia
どんなふうに使いまわしたの?
例えば、出版社XはA、Bという本を販売していて、それぞれのコードは1000, 1001です。
出版社XはA本を販売終了させて、増加改訂版のAAという本を発売しました。
出版社Xは1000という番号はもう使わないから改訂版に使っていいだろうと思い、そのコードはAと同じ1000にしました。
という感じで、増補改訂版など、元とは内容が異なる・追加された場合には基本的には別のコードを付けなければいけないのですが、
それを同じコードを使いまわしてしまったということです。
使いまわされるとどうなるの?
出版社X自体はそれで問題ないと思いましたが、コードは業界共通で、重複することはないという前提で使われるものでした。
本屋Yはお店にある本の在庫をデータベースで管理しており、本はコードで区分しています。
本屋Yは出版社XのA本の在庫を2冊持っており、AAという本を5冊入荷しました。
コードが1000の本の在庫を入荷した分だけ5増やしました。
ある時、通販でAA本の注文を受け、AA本のコードは1000なので、1000の本をお店から取り出して送りました。
しばらくしたら注文者から「注文した物と違うぞ!!!!」と電話が来ました。
と、こんな話です。
ここでミソになるのはコード1000の本が2種類あること。
本屋はコードは本によって別々で、同じ値になることはないと思っていたので、
コードがあってればOKという前提で仕事をしていたんですね。
それが、実は使いまわされていたので、コードを信用して全然違う本を送ってしまっていたんです。
例えば、これが製造業で使うロットだったら、同じロットで中身の部品のバージョンが違う、という事が出てしまいます。
※これは製造業では絶対にNGです
DBの設計にどんな問題が起きるの?
信頼できない主キーを使った場合、上の例のようにまず欲しいと思ったデータが取り出せません。
DBなどのシステムを導入する理由は業務を楽にしたい、時間がかかるチェック業務を効率化したい、ということだと思いますが、
こういった信頼できない主キーを使ってしまうと、システム化しているのにも関わらず人が手作業でチェックするハメになります。
で、ユーザーは社内情報システム部門にこう言います。
「システムを入れたせいで仕事に時間がかかるようになった。こんなシステムいらん!」
社内情報システム部門は胃をキリキリさせながらそこをなんとか・・・・とユーザーに土下座し、
作成したベンダーに八つ当たりします。
なんて、事が起こってしまいます。
実は自分が今その胃をキリキリさせている社内情報システム部門なわけだけど
DB設計時にどう対策すればいいの?
これについては著名なエンジニアの@t_wadaさんがこんなツイートをしている。
大なり小なりこういう事例をいろいろ見てきたので、自然キーの一意性が信じられなくなり、データベース設計においてプライマリキーに自然キーを使うことはなくなった / “岩波文庫がISBNコードを上書き使用している件について - Tog…” https://t.co/MWqt52yUfj
— Takuto Wada (@t_wada) 2016年11月29日
ここでのキーワードは自然キー。
自然キーと言うのは、ナチュラルキーとも良い、元々のデータモデルにあった主キーとなるデータのこと。
例えば、免許なら免許番号、車なら製造番号やナンバープレート等が挙げられる。
これに対するのが代理キー、またはサロゲートキーとも言うもので、例えばテーブルにデータを入力した時に自動的に1番、2番…と番号が割り振られ、それがキーとして扱えるもの。
要は元のデータには存在しない、必要ではないキーとして使えるデータ。
この
代理キーのほうが信用できない自然キーよりも信用できるということだと思う。
なんせ、自然キーは機械が自動的に作るものとは限らず、人間が適当につけたり、機械が重複しない一意なキーを作ったとしても
人間が間違えて違う値を帳票に書いてしまったり、といったことも十分ありえるものなので、
それだったら絶対に重複しないと保証ができる自分が書いたプログラムが作ったキーのほうがよっぽど信頼できるのもわからない話ではない。
というか自分も信頼できる主キーがなかったら複合キーにするか、こういったように代理キーを作ると思う。
今回の岩波書店の話は完全に下の記事の内容がそのまま当てはまる。
gihyo.jp
また、こういう意見もあるのでそれも紹介する。
nippondanji.blogspot.jp
自分としては、できるだけ自然キーを使うが信頼性に欠けた場合のみ代理キーを使う、という方針でテーブル設計をしていこうと改めて
考えさせられた話だった。