特にWebアプリケーションで、データベースの行識別子としてUUIDを使用することについて、どう思われますか？

質問

私はこれまで、単純さと（想定される）速度のために、データベースの主キーとして長整数を使用することを好んできました。しかし REST やRailsのようなURLスキームをオブジェクトインスタンスに使用する場合、次のようなURLになってしまいます。

http://example.com/user/783

そして、782、781、...、2、1 の ID を持つユーザーも存在するという仮定です。問題の Web アプリが、他の番号を入力して他のユーザーを認証なしに表示できないほど安全だと仮定すると、単純な連続的に割り当てられた代理キーは、特権情報かもしれないインスタンスの総数（これより古い）、この場合はユーザーも "リーク"してしまいます。(たとえば、私はstackoverflowのユーザー#726です)。

は UUID /GUIDの方が良い解決策になるでしょうか？そうすれば、このようなURLを設定することができますね。

http://example.com/user/035a46e0-6550-11dd-ad8b-0800200c9a66

必ずしも簡潔ではありませんが、表示されるユーザーに関する暗黙の情報は少なくなっています。確かに、これは「不明瞭さによるセキュリティ」（適切なセキュリティに代わるものではありません）の臭いがしますが、少なくとも少しは安全だと思われます。

その利点は、Web でアドレス指定可能なオブジェクト インスタンスに UUID を実装するコストと複雑さに見合うものでしょうか? 私は、結合を高速化するために、データベースの PK として整数の列をまだ使用したいと思います。

また、UUIDのデータベース内の表現についての質問もあります。MySQL はそれらを 36 文字の文字列として保存することを知っています。Postgres はより効率的な内部表現 (128 ビット?) を持つようですが、私自身はそれを試していません。どなたか、この件に関する経験をお持ちの方はいらっしゃいますか？

更新：URLでユーザー名だけを使用することについて質問された方へ（例, http://example.com/user/yukondude しかし、番号によってのみ識別可能な数十万の Web アプリケーション オブジェクトについてはどうでしょうか。注文、トランザクション、請求書、重複する画像名、stackoverflow の質問、...。

どのように解決するのですか?

あなたの質問のWeb側について言うことはできません。しかし、uuidsはn層アプリケーションに最適です。PK の生成は分散化できます。各クライアントは、衝突のリスクなしに独自の PK を生成します。 そして、一般的に速度の差は小さいです。

データベースが効率的なストレージデータ型(16バイト、128ビット)をサポートしていることを確認してください。 少なくとも、uuid 文字列を base64 でエンコードし、char(22) を使用することができます。

私はFirebirdでこれらを広範囲に使用し、推奨しています。