I GUID sono problematici come chiavi raggruppate a causa dell'elevata casualità. Questo problema è stato affrontato da Paul Randal nell'ultima colonna di domande e risposte di Technet Magazine:vorrei utilizzare un GUID come chiave dell'indice cluster, ma gli altri sostengono che può causare problemi di prestazioni con gli indici. È vero e, in caso affermativo, può spiegare perché?
Ora tieni presente che la discussione riguarda specificamente i cluster indici. Dici di voler utilizzare la colonna come "ID", non è chiaro se intendi come chiave cluster o solo chiave primaria. In genere i due si sovrappongono, quindi suppongo che tu voglia usarlo come indice cluster. I motivi per cui questa è una scelta sbagliata sono spiegati nel link all'articolo che ho menzionato sopra.
Per gli indici non cluster, i GUID presentano ancora alcuni problemi, ma non così grandi come quando sono la chiave cluster più a sinistra della tabella. Anche in questo caso, la casualità dei GUID introduce divisioni di pagina e frammentazione, sia solo a livello di indice non cluster (un problema molto più piccolo).
Ci sono molte leggende metropolitane sull'utilizzo del GUID che li condannano in base alle loro dimensioni (16 byte) rispetto a un int (4 byte) e promettono un terribile destino di prestazioni se vengono utilizzati. Questo è leggermente esagerato. Una chiave di dimensione 16 può essere una chiave ancora molto performante, su un modello di dati adeguatamente progettato. Mentre è vero che essere 4 volte più grande di un int si traduce in più pagine non foglia a densità inferiore negli indici, questo non è un vero problema per la stragrande maggioranza delle tabelle. La struttura del b-tree è un albero naturalmente ben bilanciato e la profondità di attraversamento dell'albero è raramente un problema, quindi cercare un valore basato sulla chiave GUID anziché su una chiave INT è simile in termini di prestazioni. Un attraversamento della pagina foglia (ad es. una scansione della tabella) non esamina le pagine non foglia e l'impatto della dimensione del GUID sulla dimensione della pagina è in genere piuttosto ridotto, poiché il record stesso è significativamente più grande dei 12 byte aggiuntivi introdotti dal GUID. Quindi prenderei il consiglio per sentito dire basato su "è 16 byte contro 4" con un granello di sale piuttosto grande. Analizza caso per caso e decidi se l'impatto dimensionale fa davvero la differenza:quanti altri le colonne sono nella tabella (ad es. quanto impatto ha la dimensione del GUID sulle pagine foglia) e quanti riferimenti lo stanno utilizzando (ad es. quanti altro le tabelle aumenteranno a causa del fatto che devono memorizzare una chiave esterna più grande).
Sto richiamando tutti questi dettagli in una sorta di difesa improvvisata dei GUID perché ultimamente hanno ricevuto molta cattiva stampa e alcuni sono immeritati. Hanno i loro pregi e sono indispensabili in qualsiasi sistema distribuito (nel momento in cui parli di movimento di dati, sia tramite replica o framework di sincronizzazione o altro). Ho visto prendere decisioni sbagliate sulla base della cattiva reputazione del GUID quando sono state evitate senza un'adeguata considerazione. Ma è vero, se devi usare un GUID come chiave cluster, assicurati di risolvere il problema della casualità:usa i GUID sequenziali quando possibile.
E infine, per rispondere alla tua domanda:se non hai un specifico motivo per utilizzare GUID, utilizzare INT.
