database - 您对使用 UUID 作为数据库行标识符有何看法，尤其是在 Web 应用程序中？

Question

为了简单和(假定的)速度，我一直倾向于使用长整数作为数据库中的主键。但是当使用 REST或对象实例的类似 Rails 的 URL 方案，然后我会得到这样的 URL:

http://example.com/user/783

然后假设还有 ID 为 782、781、...、2 和 1 的用户。假设有问题的 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 )的人来说，这对于具有唯一名称的对象实例来说效果很好，但是对于真正可以真正只能通过数字识别？订单、交易、发票、重复的图像名称、stackoverflow 问题……

Answer 1

关于您的问题的网络方面，我不能说。但是 uuid 非常适合 n 层应用程序。 PK 生成可以是分散的:每个客户端生成它自己的 pk 而没有冲突的风险。而且速度差异一般很小。

确保您的数据库支持有效的存储数据类型(16 字节，128 位)。至少你可以在 base64 中编码 uuid 字符串并使用 char(22)。

我已经在 Firebird 中广泛使用它们并推荐。