I never liked GUIDs, not really using them in most of my development until I had a conversation many years ago with Andy Warren. At the time he was working for a company as a development manager and building in house applications. We were debating the ways in which we built applications, me mainly using web technologies, and him still using client-server technologies at a call center. We debated the various pros and cons of both methods, and one thing he said stuck with me for many years.

At the time I often used (and still do use) identities as the surrogate and PK of many of my tables. That’s another debate, and I don’t want to digress here. Instead I wanted to point out an interesting item that Andy explained to me years ago about the advantages of GUIDs over identities.

The client can create them.

That’s pretty interesting, especially in cases where you need to insert a parent and a few child records from a remote machine. You can create the parent record, and child records, without a round trip to the database, and still have them related. That’s something that isn’t easy to do with identities, and it could easily cause lots of breakage in your client applications.

An identity is generated on the server. You insert a row, you then use @@scope_identity, not @@identity, to retrieve the identity of the inserted row. You can then use that and insert it in your child records. It’s quick, clean, and it often follows the workflow for an application.

However a GUID, which is supposed to be unique (it isn’t always), can be generated on the client. A client can’t generate an identity since it can’t be sure of the concurrency issues with other clients. A GUID can be built on the client, it’s likely unique, and so the client can already know the surrogate key for the parent, thus the FK for the child rows, and send all that back with a minimum of round trips to the server.

There are different ways to create a GUID on the client, depending on your technology, but they all essentially work the same as the NEWID() function in SQL Server. You’d have to look for a function or API depending on your client technology to do this.

It’s an interesting idea, especially with disconnected clients, which might need to update a local database of some sort, and then have that replicated or sync’d with a master database later. By using GUIDs for the surrogate keys, you don’t need to set aside ranges of identities, or worry about collisions for the most part. Just be aware there could be issues, and this StackOverflow question highlights some of the issues.