Algoritmus je zdokumentován lidmi z SQL Server zde:Jak jsou GUID porovnány v SQL Server 2005? Zde cituji (protože je to starý článek, který může být za pár let navždy pryč)
Obecně platí, že srovnání rovnosti dává velký smysl s hodnotami jednoznačných identifikátorů. Pokud však zjistíte, že potřebujete obecné řazení, možná se díváte na nesprávný datový typ a místo toho byste měli zvážit různé typy celých čísel.
Pokud se po pečlivém zvážení rozhodnete objednat na sloupci uniqueidentifier, můžete být překvapeni, co dostanete zpět.
Vzhledem k těmto dvěma hodnotám uniqueidentifier:
@g1='55666BEE-B3A0-4BF5-81A7-86FF976E763F' @g2 ='8DD5BCA5-6ABE-4F73-B4B7-393AE6BBB849'
Mnoho lidí si myslí, že @g1 je menší než @g2, protože '55666BEE' je jistě menší než '8DD5BCA5'. Takto však SQL Server2005 porovnává hodnoty uniqueidentifier.
Porovnání se provádí pohledem na bajtové „skupiny“ zprava doleva a zleva doprava v rámci bajtové „skupiny“. Skupina bajtů je to, co je odděleno znakem '-'. Technickěji se podíváme na bajty {10 až 15}nejprve, potom {8-9}, potom {6-7}, potom {4-5} a nakonec {0 až 3}.
V tomto konkrétním příkladu bychom začali porovnáním „86FF976E763F“ s „393AE6BBB849“. Okamžitě vidíme, že @g2 je skutečně větší než @g1.
Všimněte si, že v jazycích .NET mají hodnoty Guid jiné výchozí řazení než v SQL Server. Pokud zjistíte, že je potřeba objednat pole nebo seznam Guid pomocí sémantiky SQL Serveru, můžete místo toho použít anarray nebo seznam SqlGuid, který implementuje IComparable in away, což je konzistentní se sémantikou SQL Server.
Navíc řazení následuje endianness bajtových skupin (viz zde:Globálně jedinečný identifikátor). Skupiny 10-15 a 8-9 jsou uloženy jako big endian (odpovídající Data4 v článku na wikipedii), takže jsou porovnávány jako big endian. Ostatní skupiny jsou porovnávány pomocí little endian.