A COMB-killer

I wrote an article in late 2001 called "The Cost of GUIDs as Primary Keys". The article was about an INSERT-problem you might run into when creating GUIDs with NEWID(), and using the GUIDs for primary keys in very large tables. The problem was that the GUIDs were random numbers in Windows 2000 and beyond. I proposed a solution that I called COMBs instead. They were still GUIDs, but created in a way that made them kind of sequential.

My Friend Tibor Karaszi told me about the new function called NEWSEQUENTIALID() in Yukon (SQL Server 2005) beta 2. It deals with the same problem, but it creates true sequential GUIDs, unlike my COMBs where just the six bytes to the right were sequential (or actually based on current date and time).

Here's an example (start reading the result values from the right):

SELECT NEWSEQUENTIALID()
UNION ALL
SELECT NEWSEQUENTIALID()
UNION ALL
SELECT NEWSEQUENTIALID()

A9E66E00-E103-D911-9A0E-000C29814600
AAE66E00-E103-D911-9A0E-000C29814600
ABE66E00-E103-D911-9A0E-000C29814600