UUID

database

UUID (ゆーゆーあいでぃー)

UUID とは、 Universally Unique Identifier の略。
「Universally Unique」、つまり、世界中で重複しないIDのこと。

では、「Universally Unique ではないID」とはどういうものかというと、通常のIDのこと。
たいていのデータベース製品では、各テーブルのデフォルトのIDは数値。新しいレコードが追加されるたびに ID が割り振られるが、そのIDの値は、 1, 2, 3, ... と、1 から順番に割り振られていくのが普通。

これだと、そのテーブル内では重複しない。
しかし、別のテーブルもまたIDは 1, 2, 3, ... と割り振られていくので、これは、「Universally Unique」ではない。

UUID は、UUID用の生成アルゴリズムに従って生成され、以下のような類の値を取る。
6bbecba2-a915-4a0f-ad53-55389c605ebb

この値は、規定のアルゴリズムに則って生成されたものであれば、世界中のどこで探しても、別のところで生成された同じ値のものを見つけることはまずできないとされている。
「何万年に1回みつかるかどうか」とか、そういうレベルの話(数字は適当) 。

UUIDを使う理由は、主に2つある。
1つは、IDを推測されたくない場合。

たとえば、このサイトの「ITセンスがよくなるエクセル講座」のページは以下のもの。
ここで、最後の「9」は、講座データベースでのこの講座のIDをそのまま利用している。
https://forum.pc5bai.com/lesson/course/9/

となると、「さて、ほかのページのIDは、8とか10とかだな」と、推測されやすくなる。
この状況は、システムの脆弱性をつこうと種々のページの動作を調査している悪意ある利用者に有利に働く。

そこで、そのような状況を避けたいならば、講座のIDをUUIDのような値にする。

UUIDの使途はもう1つは、データベースのテーブルが分散している場合。
世界規模で提供されているサービス(たとえばTwitter)では、利用者データ(たとえばツイート)を保存するテーブルがどこかにある1台のデータベースサーバ内の1つのテーブルに収まっているわけではない。
このような状況では、以下の2つの方法のどちらを選択するかとなれば、後者のほうが圧倒的に容易な実装なので、IDには、UUIDが選択されることになる。

実装アイデア1:
1. 個別のデータベースサーバが利用者データを保存する都度IDとして利用可能な数値を調べる
2. 他のデータベースサーバにはその値を使わないようにと通知し、同意を得る
3. その数値をキーとしてデータを保存する
実装アイデア2:
1. IDはUUIDとする