Ik ben het 100% met je eens - gebruik een INT IDENTITY is veel beter!
GUID's lijken misschien een natuurlijke keuze voor uw primaire sleutel - en als het echt moet, zou u waarschijnlijk kunnen argumenteren om het te gebruiken voor de PRIMARY KEY van de tabel. Wat ik sterk zou aanraden niet te doen is de GUID-kolom gebruiken als de clustersleutel , wat SQL Server standaard doet, tenzij u specifiek aangeeft dat niet te doen.
Je moet echt twee zaken uit elkaar houden:
1) de primaire sleutel is een logische constructie - een van de kandidaatsleutels die elke rij in uw tabel op unieke en betrouwbare wijze identificeert. Dit kan werkelijk alles zijn - een INT, een GUID, een string - kies wat het meest logisch is voor uw scenario.
2) de clustersleutel (de kolom of kolommen die de "geclusterde index" in de tabel definiëren) - dit is een fysiek opslaggerelateerd ding, en hier is een klein, stabiel, steeds groter wordend gegevenstype uw beste keuze - INT of BIGINT als uw standaardoptie.
Standaard wordt de primaire sleutel op een SQL Server-tabel ook gebruikt als de clustersleutel - maar dat hoeft niet zo te zijn! Ik heb persoonlijk enorme prestatieverbeteringen gezien bij het opsplitsen van de vorige op GUID gebaseerde primaire / geclusterde sleutel in twee afzonderlijke sleutels - de primaire (logische) sleutel op de GUID en de clustering (bestel) sleutel op een afzonderlijke INT IDENTITY (1, 1) kolom.
Als Kimberly Tripp - de Queen of Indexing - en anderen hebben al heel vaak verklaard - een GUID omdat de clustersleutel niet optimaal is, omdat dit door zijn willekeur zal leiden tot enorme pagina- en indexfragmentatie en tot over het algemeen slechte prestaties.
Ja, ik weet het - er is newsequentialid() in SQL Server 2005 en hoger - maar zelfs dat is niet echt en volledig sequentieel en heeft dus ook last van dezelfde problemen als de GUID - alleen iets minder prominent.
Dan is er nog een ander probleem om te overwegen:de clustersleutel op een tabel wordt ook toegevoegd aan elk item op elke niet-geclusterde index op uw tabel - dus u wilt er zeker van zijn dat deze zo klein mogelijk is. Normaal gesproken zou een INT met meer dan 2 miljard rijen voldoende moeten zijn voor de overgrote meerderheid van de tabellen - en vergeleken met een GUID als clustersleutel, kunt u honderden megabytes aan opslagruimte op schijf en in servergeheugen besparen.
Snelle berekening - INT versus GUID gebruiken als primaire en clustersleutel:
- Basistabel met 1.000.000 rijen (3,8 MB vs. 15,26 MB)
- 6 niet-geclusterde indexen (22,89 MB versus 91,55 MB)
TOTAAL:25 MB versus 106 MB - en dat is slechts op een enkele tafel!
Nog wat stof tot nadenken - uitstekend werk van Kimberly Tripp - lees het, lees het nog eens, verwerk het! Het is eigenlijk het SQL Server-indexeringsevangelie.
- GUID's als PRIMAIRE SLEUTEL en/of geclusterde sleutel
- Het geclusterde indexdebat gaat door
- Steeds toenemende clusteringsleutel - het geclusterde indexdebat..........nogmaals!
- Schijfruimte is goedkoop - dat is niet het punt!