Na ez is egy őrült ötlet de miért ne... Vajon az alábbi lekérdezésnél melyik GUID nagyobb?
DECLARE @A uniqueidentifier = '0CB2DC09-D93C-4CFF-8D49-000000000001';
DECLARE @B uniqueidentifier = '66454F18-F2D1-4934-85CD-000000000001';
SELECT @A AS [A], @B AS [B],
CASE WHEN @A > @B THEN 'A' ELSE 'B' END AS [GuidCompare],
CASE WHEN CAST(@A as varchar(36)) > CAST(@B AS varchar(36)) THEN 'A' ELSE 'B' END AS [StringCompare]
GO
Szerintem itt mindenki a B-re tenné a voksát, igaz? Igaz is, ha szövegként hasonlítom össze - StringCompare oszlop. Amenniyben GUID-ként kellene összehasonlítani, akkor már ez nem igaz, ekkor az A a nagyobb - GuidCompare oszlop.
Miért? Rém egyszerű: az SQL server a uniqueidentifer értékeket visszafele hasonlítja össze. Először a 10-15, majd a 8-9, 6-7, 4-5 és legvégül a 0-3 byte-okat hasonlítja össze, esetünkben:
10-15 byte:
- A: 000000000001 azaz 00000000 00000000 00000000 00000000 00000000 00000001
- B: 000000000001 azaz 00000000 00000000 00000000 00000000 00000000 00000001
Ezek megegyeznek, az összehasonlítás megy tovább.
8-9 byte:
- A: 8D49 azaz 10001101 01001001
- B: 85CD azaz 10000101 11001101
Itt már látszik, hogy az A a nagyobb, mind a bináris mind a hexadecimális számoknál. Elvileg az összehasonlítás nem megy tovább esetünkben, mert itt már látszik, hogy melyik a nagyobb.
Ennek alapján már értelmet is nyert az A válasz.