What's your opinion on using UUIDs as database row identifiers, particularly in web apps?

Question

I\'ve always preferred to use long integers as primary keys in databases, for simplicity and (assumed) speed. But when using a REST or Rails-like URL scheme for object insta

Answer 1

I don't think a GUID gives you many benefits. Users hate long, incomprehensible URLs.

Create a shorter ID that you can map to the URL, or enforce a unique user name convention (http://example.com/user/brianly). The guys at 37Signals would probably mock you for worrying about something like this when it comes to a web app.

Incidentally you can force your database to start creating integer IDs from a base value.

Answer 2

I can answer you that in SQL server if you use a uniqueidentifier (GUID) datatype and use the NEWID() function to create values you will get horrible fragmentation because of page splits. The reason is that when using NEWID() the value generated is not sequential. SQL 2005 added the NEWSEQUANTIAL() function to remedy that

One way to still use GUID and int is to have a guid and an int in a table so that the guid maps to the int. the guid is used externally but the int internally in the DB

for example

457180FB-C2EA-48DF-8BEF-458573DA1C10    1
9A70FF3C-B7DA-4593-93AE-4A8945943C8A    2

1 and 2 will be used in joins and the guids in the web app. This table will be pretty narrow and should be pretty fast to query

Answer 3

I've tried both in real web apps.

My opinion is that it is preferable to use integers and have short, comprehensible urls.

As a developer, it feels a little bit awful seeing sequential integers and knowing that some information about total record count is leaking out, but honestly - most people probably don't care, and that information has never really been critical to my businesses.

Having long ugly UUID urls seems to me like much more of a turn off to normal users.