GUID's zijn problematisch als geclusterde sleutels vanwege de hoge willekeurigheid. Dit probleem is behandeld door Paul Randal in de laatste Q&A-kolom van Technet Magazine:ik zou graag een GUID gebruiken als de geclusterde indexsleutel, maar de anderen beweren dat dit kan leiden tot prestatieproblemen met indexen. Klopt dit en zo ja, kunt u uitleggen waarom?
Houd er rekening mee dat de discussie specifiek gaat over geclusterd indexen. Je zegt dat je de kolom als 'ID' wilt gebruiken, het is onduidelijk of je het als clustered key of alleen als primary key bedoelt. Meestal overlappen de twee elkaar, dus ik neem aan dat je het als geclusterde index wilt gebruiken. De redenen waarom dat een slechte keuze is, worden uitgelegd in de link naar het artikel dat ik hierboven noemde.
Voor niet-geclusterde indexen hebben GUID's nog wat problemen, maar lang niet zo groot als wanneer ze de meest linkse geclusterde sleutel van de tabel zijn. Nogmaals, de willekeur van GUID's introduceert paginasplitsingen en fragmentatie, zij het alleen op het niet-geclusterde indexniveau (een veel kleiner probleem).
Er zijn veel stedelijke legendes rond het GUID-gebruik die ze veroordelen op basis van hun grootte (16 bytes) in vergelijking met een int (4 bytes) en die vreselijke prestatie-doom beloven als ze worden gebruikt. Dit is enigszins overdreven. Een sleutel van maat 16 kan nog steeds een zeer performante sleutel zijn, op een goed ontworpen datamodel. Hoewel het waar is dat 4 keer zo groot zijn als een int resulteert in meer niet-bladige pagina's met een lagere dichtheid in indexen is dit voor de overgrote meerderheid van de tabellen geen echte zorg. De b-tree structuur is een natuurlijk goed uitgebalanceerde boom en de diepte van boomtraversal is zelden een probleem, dus het zoeken naar een waarde op basis van een GUID-sleutel in tegenstelling tot een INT-sleutel is vergelijkbaar in prestaties. Een leaf-page traversal (dwz een tabelscan) kijkt niet naar de niet-bladige pagina's, en de impact van de GUID-grootte op de paginagrootte is meestal vrij klein, omdat het record zelf aanzienlijk groter is dan de extra 12 bytes die zijn geïntroduceerd door de GUID. Dus ik zou het advies van horen zeggen op basis van 'is 16 bytes vs. 4' met een, vrij grote, korrel zout nemen. Analyseer van geval tot geval en beslis of de impact van de grootte echt een verschil maakt:hoeveel andere kolommen staan in de tabel (d.w.z. hoeveel invloed heeft de GUID-grootte op de bladpagina's) en hoeveel referenties het gebruiken (d.w.z. hoeveel andere tabellen zullen toenemen omdat ze een grotere externe sleutel moeten opslaan).
Ik noem al deze details in een soort geïmproviseerde verdediging van GUID's omdat ze de laatste tijd veel slechte pers hebben gekregen en sommige zijn onverdiend. Ze hebben hun verdiensten en zijn onmisbaar in elk gedistribueerd systeem (op het moment dat je het hebt over gegevensverplaatsing, of het nu via replicatie of synchronisatieframework is of wat dan ook). Ik heb gezien dat slechte beslissingen werden genomen op basis van de slechte reputatie van de GUID, terwijl ze werden gemeden zonder er goed over na te denken. Maar het is waar, als je een GUID als geclusterde sleutel moet gebruiken, zorg er dan voor dat je het probleem van willekeur aanpakt:gebruik sequentiële richtlijnen indien mogelijk.
En tot slot, om je vraag te beantwoorden:als je geen specifieke . hebt reden om GUID's te gebruiken, gebruik INT's.