Google Groups : microsoft.public.sqlserver.programming: "I've only encountered one scenario where using a GUID made sense.
Especially when you consider their massive storage size.

If you think about it COM objects use GUID's and the reason is, when a COM
object is registered in the registry which is a crude database, different
developers have to make sure their GUID's don't collide. In other words,
records created in a other locations could be combined and possibly collide.
The random nature of a GUID protects against that.

The only time in my database work that I felt a GUID was justified as a PK
was a CRM application. Sales agents on the road and office staff would
create records which could be combined in the future. We needed to ensure
that new records created in any location could be combined without PK
collisions.

However, that doesn't mean I always use IDENTITY columns. Sometimes the
table itself has a unique field that will not change and that is sometimes a
good choice. "