Jeg er 100 % enig med dig - ved at bruge en INT IDENTITY er meget bedre!
GUID'er kan synes at være et naturligt valg for din primære nøgle - og hvis du virkelig skal, kan du sikkert argumentere for at bruge den til den PRIMÆRE NØGLE i tabellen. Hvad jeg kraftigt vil anbefale ikke at gøre er at bruge GUID-kolonnen som klyngenøgle , hvilket SQL Server gør som standard, medmindre du specifikt fortæller den ikke at gøre det.
Du skal virkelig holde to problemer adskilt:
1) den primære nøgle er en logisk konstruktion - en af kandidatnøglerne, der unikt og pålideligt identificerer hver række i din tabel. Dette kan virkelig være hvad som helst - en INT, en GUID, en streng - vælg det, der giver mest mening for dit scenarie.
2) klyngerøglen (den eller de kolonner, der definerer "klyngeindekset" i tabellen) - dette er en fysisk lagringsrelateret ting, og her er en lille, stabil, stadigt stigende datatype dit bedste valg - INT eller BIGINT som din standardindstilling.
Som standard bruges den primære nøgle på en SQL Server-tabel også som clustering-nøglen - men sådan behøver det ikke være! Jeg har personligt set massive præstationsgevinster, når den tidligere GUID-baserede primære/klyngede nøgle blev opdelt i to separate nøgler - den primære (logiske) nøgle på GUID'en og klynge- (bestillings-) nøglen på en separat INT IDENTITY(1, 1) kolonne.
Som Kimberly Tripp - The Queen of Indexing - og andre har udtalt rigtig mange gange - en GUID som klyngingsnøgle er ikke optimal, da den på grund af dens tilfældighed vil føre til massiv side- og indeksfragmentering og til generelt dårlig ydeevne.
Ja, jeg ved det - der er newsequentialid() i SQL Server 2005 og nyere - men selv det er ikke helt sekventielt og lider derfor også af de samme problemer som GUID'en - bare lidt mindre fremtrædende.
Så er der et andet problem at overveje:klyngingsnøglen på et bord vil også blive tilføjet til hver eneste indgang på hvert ikke-klyngede indeks på din tabel - så du vil virkelig gerne sikre dig, at den er så lille som muligt. Typisk burde en INT med 2+ milliarder rækker være tilstrækkelig til langt de fleste tabeller – og sammenlignet med en GUID som clustering-nøgle kan du spare dig selv for hundredvis af megabyte lager på disk og i serverhukommelse.
Hurtig beregning - brug af INT vs. GUID som primær og klyngenøgle:
- Basistabel med 1.000.000 rækker (3,8 MB vs. 15,26 MB)
- 6 ikke-klyngede indekser (22,89 MB vs. 91,55 MB)
TOTAL:25 MB vs. 106 MB - og det er bare på et enkelt bord!
Lidt mere stof til eftertanke - fremragende ting af Kimberly Tripp - læs det, læs det igen, fordøj det! Det er virkelig SQL Server-indekseringsevangeliet.
- GUID'er som PRIMÆR NØGLE og/eller grupperet nøgle
- Debatten om klynget indeks fortsætter
- Stadig voksende klyngenøgle - The Clustered Index Debate...........igen!
- Diskplads er billig - det er ikke pointen!