为了简单和(假设)速度，我一直更喜欢在数据库中使用长整数作为主键.但是，当对对象实例使用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)的人来说，这对于名称唯一的对象实例来说很好，但是对于那些真正只能通过数字识别的无数Web应用程序对象又如何呢？订单、交易、发票、重复图像名称、堆栈溢出问题.