Frederik lo riassume bene, ed è proprio ciò che predica anche Kimberly Tripp:la chiave di clustering dovrebbe essere stabile (non cambia mai), in continuo aumento (IDENTITY INT), piccola e unica.
Nel tuo scenario, preferirei di gran lunga inserire la chiave di clustering nella colonna BIGINT piuttosto che nella colonna VARCHAR(80).
Prima di tutto, con la colonna BIGINT, è ragionevolmente facile imporre l'univocità (se non imposti e garantisci l'unicità da solo, SQL Server aggiungerà un "unificatore" di 4 byte a ciascuna delle tue righe) ed è MOLTO in media inferiore a un VARCHAR(80).
Perché la taglia è così importante? La chiave di clustering verrà aggiunta anche a CIASCUNO e a ciascuno dei tuoi indici non cluster, quindi se hai molte righe e molti indici non cluster, avere 40-80 byte contro 8 byte può creare rapidamente un ENORME differenza.
Inoltre, un altro suggerimento per le prestazioni:per evitare le cosiddette ricerche di segnalibri (da un valore nell'indice non cluster tramite la chiave di cluster nelle pagine foglia di dati effettive), SQL Server 2005 ha introdotto la nozione di "colonne incluse" nei tuoi indici non cluster. Questi sono estremamente utili e spesso trascurati. Se le tue query richiedono spesso i campi dell'indice più solo uno o due altri campi del database, considera di includerli per ottenere ciò che viene chiamato "indici di copertura". Ancora una volta, vedi l'eccellente articolo di Kimberly Tripp:è la dea dell'indicizzazione di SQL Server! :-) e lei può spiegare quella roba molto meglio di me...
Quindi, per riassumere:metti la tua chiave di clustering su una colonna piccola, stabile e univoca - e andrà benissimo!
Marco
