A synergy-s táblákban az ID mezők általában nem szokványos INT(1,1) IDENTITY-k, hanem GUID típusú adatok.
A GUID (Globally Unique IDentifier), ahogy a neve is mutatja, egy egyedi azonosító, mely az UUID (Universally Unique IDentifier) egy megvalósítása. Ennek megfelelően egy 16 bájt hosszúságú azonosítóról beszélhetünk. Generálható teljesen random módom, vagy bizonyos paraméterek felhasználásával. A szabvány első verziója a MAC címet és egy 100 ns felbontású időbélyeget (kezdőpontja a Gergely-naptár első napja) használt fel, viszont így megjelent egy teljesen nyilvánvaló biztonsági rés: a GUID-ból egyértelműen meghatározható a generáló gép azonosítója és a generálás ideje. Épp ezért a négyes verzió (a Microsoft is ezt használja, az egyik legelterjedtebb) már egy pszeudo-random számot használ.
Ha MSSQL-ben akarunk ilyen ID-t használni, akkor azt a uniqueidentifier kulcsszóval tehetjük. Ebben az esetben vagy megadjuk alapértelmezett értéknek a NEWID() függvényt, vagy minden INSERT-nél külön be kell illeszteni a egy ID-t a NEWID()-vel.
NEWID() vs. IDENTITY
Egyrészt egy ilyen GUID jóval több helyet foglal, mint egy szokványos INT típusú IDENTITY, másrészt az utóbbival ellentétben a generált kulcsok nincsenek sorrendben. Ez azért probléma, mert alapesetben az SQL Server klaszterezett indexelést használ. Mivel ez összefügg az adatok fizikai elhelyezkedésével, így minden egyes NEWID()-s beillesztés egyben az adatok átrendezését is jelenti.
Másrészt az ID-k mérete is megnövekszik, hiszen a szokványos INT helyett egy 16 bájtos adatot kell tárolni, plusz a klaszterezés és nem szekvenciális ID-k együttes hatása miatt nagyon megugrik a töredezettség mértéke is.
Ezekre a problémákra jelent részben megoldást, ha a NEWID() helyett a NEWSEQUENTIALID()-t használjuk: ez a módszer garantálja, hogy az generált ID nagyobb lesz a számítógép bekapcsolása óta generált összes GUID-nél. Ezen felül a generáláshoz felhasználja a MAC címet is, így elérhető, hogy két különböző gépen se generálhasson megegyező GUID-t.
Ez a tulajdonság teszi jól használhatóvá az ilyen típusú ID-kat: ha több táblából akarunk adatokat egyesíteni, amik érkezhetnek akár több gépről is (például adattárházak esetén), akkor biztosak lehetünk benne, hogy nem lesz azonos kulcs az összefésült adatok között.
Általában tehát célszerű az IDENTITY-t választani, viszont ha a későbbiekben táblákat kell majd egybeolvasztani, akkor a NEWSEQUENTIALID() segítségével elkerülhető a kulcsok ütközése.
Akit részletesebben érdekel a téma:
http://en.wikipedia.org/wiki/Globally_unique_identifier
http://en.wikipedia.org/wiki/Universally_unique_identifier
Pár cikk a NEWID() vs. IDENTITY témában:
http://mssql.wordpress.com/2007/07/28/primary-key-newid-vs-identity-column/
http://www.sqlteam.com/article/uniqueidentifier-vs-identity
http://www.mssqltips.com/sqlservertip/1600/auto-generated-sql-server-keys-with-the-uniqueidentifier-or-identity/
