Unieke identifier (guid) als primaire sleutel in databaseontwerp

Een 128-bits GUID (uniqueidentifier ) sleutel is natuurlijk 4x groter dan een 32-bits int sleutel. Er zijn echter een paar belangrijke voordelen:

• Geen "IDENTITY INSERT"-probleem bij het samenvoegen van inhoud
• Als je een COMB-waarde gebruikt in plaats van NEWSEQUENTIALID(), krijg je een "gratis" INSERT-tijdstempel. Je kunt zelfs SELECT van de primaire sleutel op basis van een datum/tijdbereik als je wilt met een paar mooie CAST() oproepen.
• Ze zijn wereldwijd uniek, wat zo nu en dan best handig blijkt te zijn.
• Omdat het niet nodig is om hoogwatermerken te volgen, kan uw BL-laag de waarde toewijzen in plaats van SQL Server, waardoor de stap van SELECT scope_identity() wordt geëlimineerd. om de primaire sleutel te krijgen na een invoeging.
• Als het ook maar enigszins mogelijk is dat je meer dan 2 miljard records hebt, moet je bigint gebruiken (64 bits) in plaats van int . Zodra u dat doet, uniqueidentifier is slechts twee keer zo groot als een bigint .
• Het gebruik van GUID's maakt het veiliger om sleutels in URL's, enz. vrij te geven zonder uzelf bloot te stellen aan 'guess-the-ID'-aanvallen.
• Tussen hoe SQL Server pagina's van schijf laadt en hoe processors nu meestal 64-bits zijn, betekent het feit dat een getal 128 bits is in plaats van 32 niet dat het 4x langer duurt om te vergelijken. De laatste test die ik zag, toonde aan dat GUID's bijna net zo snel zijn.
• Indexgrootte hangt af van hoeveel kolommen zijn opgenomen. Hoewel de GUID's zelf groter zijn, kunnen de extra 8 of 12 bytes onbeduidend zijn in vergelijking met de andere kolommen in de index.

Uiteindelijk is het misschien niet de moeite waard om de voordelen van een GUID te verliezen als u een klein prestatievoordeel uitknijpt door gehele getallen te gebruiken. Test het empirisch en beslis zelf.

Persoonlijk gebruik ik nog steeds beide, afhankelijk van de situatie, maar de beslissende factor is in mijn geval nooit echt neergekomen op prestaties.