SQLAP読書会 「シュードキー：ニートフリーク(疑似キー潔癖症)」

ID関連の話は尽きない様でした

参考

　
http://www.slideshare.net/asuenami/ss-38153745
http://makopi23.blog.fc2.com/blog-entry-147.html
http://makopi23.blog.fc2.com/blog-entry-73.html
http://makopi23.blog.fc2.com/blog-entry-77.html

SQLアンチパターン

基本的にはAUTO_INCREMENTを使う

欠番を埋めるのは自分でやった人はおらず、引き継いだシステムがそうなっていたという人がいたくらいでした。主キーの変更はリスクがかなり大きいことは共通の見解のようです。

終始話していたのはMySQLでいうAUTO_INCREMENTの機能を使って自動的に採番するという方法。IDの振り間違いや変更はできなくなるので手軽で効果的な方法だということだと思います。ただ、自然キーを使えるならそのほうがいいのではないかとは思います。
現在のDBでIDが枯渇を心配するような状況にはならない。枯渇が心配されるような状況では他の問題が発生しているからだ。

仕様のID≠主キーのID

仕様書にIDという名のカラムがあり、それを主キーとして使っていたが仕様変更でIDが変わる。という案件で、よくよく聞いてみると表示する際のソート順を決めるためのものだという話だった。
ソート用のカラムを追加してお客さんがそれを自由に変更できるようにするということはよくやるようでした。

AUTO_INCREMENTではダメな場合もある

かなり多くのリクエスト(例えば、Twitterやfacebook)の場合AUTO_INCREMENTでは対応出来ない。AUTO_INCREMENTは、insertが並列に実行でいない。一つづつ採番をする必要があるためである。insertがボトルネックになることでシステムとして立ち行かなくなるとのこと。
RailsはAUTO_INCREMENTしかなく、脆弱性といえる。ただそうなる頃にはRails自体が耐えられなくなっている。

AUTO_INCREMENTでも何とかする方法も

各サーバーで事前にIDをいくつか採番してもらっておいて、insert時にはそのIDを使うと言うもの。採番が行われるタイミングが分散するので採番の部分でボトルネックは軽減される。サーバーが落ちた場合取得しておいたIDは欠番になる。

UUIDを使う

各サーバーで一意のIDが生成できれば採番する必要がない。そのためにUUIDを使う場合がある。UUIDは非常に文字列として長く容量を食ってしまう。

各社の対応

UUIDまで容量を食わず、各サーバー毎に一意のIDを発行するために様々な方法をとっているようです。
参考： http://qiita.com/daisy1754/items/98a6e6b17d8161eab081