v4とv7のどちらを使うか
v4は122ビットすべてが乱数です。値を見ても、いつ作られたか、どこで作られたかは分かりません。公開URLに載る識別子や招待リンクのように、作られた順序を隠したい場面に向いています。
v7は先頭48ビットがミリ秒のタイムスタンプで、残りが乱数です。そのため文字列をそのまま並べ替えると作成順になります。データベースの主キー、ログの識別子、イベントIDなど、時系列が役に立つ場面で使います。ただし作成時刻が値から読めてしまうので、それを知られたくない場合はv4を選んでください。
NILはすべて0の特別な値です。NULLを受け付けない列に「まだ無い」を入れるときのプレースホルダーとして使います。
データベースの主キーに使うとき
連番の代わりにUUIDを主キーにすると、複数のサーバーが相談せずにキーを作れますし、URLに出てもほかの行を推測されません。
問題はv4の乱数性です。B-treeインデックスは新しいキーが末尾に付くときが最も効率的ですが、v4は毎回インデックスの真ん中の適当な場所に入るのでページ分割が続きます。テーブルが大きくなるほど書き込みが遅くなり、インデックスも膨らみます。v7は値が時間とともに増えて新しいキーが必ず末尾に付くため、この問題を避けられます。新しく作るテーブルならv7が無難な既定値です。
MySQLなら BINARY(16)、PostgreSQLなら uuid 型に入れてください。36文字の文字列で保存すると1行あたり20バイト余分にかかり、比較も遅くなります。
ハイフンなしの形
ハイフンは表記上の約束であって値の一部ではありません。ファイル名やクーポンコード、一部のAPIでは32文字の詰めた形を使います。大文字も同じく見せ方の違いで、2つのUUIDを比べるときは先に小文字へそろえるのが安全です。
まとめて生成するとき
このツールはv7を複数作るとき、生成した順序を保ちます。同じミリ秒に作られるとタイムスタンプが同じになって順序が崩れるため、乱数部分の一部をカウンターとして使っています。一覧をそのままコピーしても並び順は保たれます。