Frederik sammanfattar det fint, och det är egentligen vad Kimberly Tripp också predikar:klustringsnyckeln ska vara stabil (förändras aldrig), ständigt ökande (IDENTITY INT), liten och unik.
I ditt scenario skulle jag mycket hellre lägga klustringsnyckeln på BIGINT-kolumnen snarare än VARCHAR(80)-kolumnen.
Först och främst, med BIGINT-kolumnen är det ganska enkelt att framtvinga unikhet (om du inte upprätthåller och garanterar unikhet själv, kommer SQL Server att lägga till en 4-byte "uniquefier" till var och en av dina rader) och det är MYCKET mindre i genomsnitt än en VARCHAR(80).
Varför är storleken så viktig? Klustringsnyckeln kommer också att läggas till i VARJE och vart och ett av dina icke-klustrade index - så om du har många rader och många icke-klustrade index, kan det snabbt bli en ENORM att ha 40-80 byte mot 8 byte skillnad.
Ett annat prestandatips:för att undvika de så kallade bokmärkessökningarna (från ett värde i ditt icke-klustrade index via klustringsnyckeln till de faktiska databladssidorna), har SQL Server 2005 introducerat begreppet "inkluderade kolumner" i dina icke-klustrade index. De är oerhört hjälpsamma och förbises ofta. Om dina frågor ofta kräver indexfälten plus bara ett eller två andra fält från databasen, överväg att inkludera dessa för att uppnå vad som kallas "täckande index". Återigen - se Kimberly Tripps utmärkta artikel - hon är SQL Server Indexing Goddess! :-) och hon kan förklara det där mycket bättre än jag...
Så för att sammanfatta det:lägg din klustringsnyckel på en liten, stabil, unik kolumn - och du kommer att klara dig bra!
Marc