Performance value of COMB guids

Question

Jimmy Nilsson discusses his COMB guid concept here. This concept is popular in NHibernate, among other circles, for its supposed performance value over standard GUIDs which

Answer 1

I'd suggest that you're not seeing the order benefit because the target table has no PK. So, it's the conversion overhead you're seeing. IF it has a PK, the 585k rows must still be sorted on insert. How does SQL know it's semi-sorted?

Now, if it was 5,850 x 100 row inserts, then you may see some benefit because the new rows will go "at the end" not "in the middle" so reducing page splits and overhead.

I'd go further and say that the article is dated 2002, and is for SQL 2000, and has been overtaken by real life.

In SQL Server 2005 we have SEQUENTIAL GUIDs to allow strictly monotonic GUIDs to solve some issues. The GUID as PK has been done here too: recent example: INT vs Unique-Identifier for ID field in database with 3rd party links.

If an ORM dictates GUID as a PK rather than a natural key or standard int-based surrogate key, that's a severe limitation of the ORM. And a case of the client tail wagging the database dog.