Frederik opsummerer det fint, og det er egentlig også det, Kimberly Tripp prædiker:clustering-nøglen skal være stabil (ændrer sig aldrig), stadig stigende (IDENTITY INT), lille og unik.
I dit scenarie vil jeg meget hellere placere klyngingsnøglen på BIGINT-kolonnen frem for VARCHAR(80)-kolonnen.
Først og fremmest, med BIGINT-kolonnen er det rimeligt nemt at håndhæve unikhed (hvis du ikke selv håndhæver og garanterer unikhed, tilføjer SQL Server en 4-byte "uniquefier" til hver og en af dine rækker), og det er MEGET mindre i gennemsnit end en VARCHAR(80).
Hvorfor er størrelsen så vigtig? Klyngerøglen vil også blive føjet til HVER og hver eneste af dine ikke-klyngede indekser - så hvis du har mange rækker og mange ikke-klyngede indekser, kan det hurtigt gøre en KÆMPE at have 40-80 byte vs. 8 byte forskel.
Også et andet præstationstip:for at undgå de såkaldte bogmærkeopslag (fra en værdi i dit ikke-klyngede indeks via clustering-nøglen til de faktiske databladsider), har SQL Server 2005 introduceret begrebet "inkluderede kolonner" i dine ikke-klyngede indekser. De er yderst hjælpsomme og ofte overset. Hvis dine forespørgsler ofte kræver indeksfelterne plus blot et eller to andre felter fra databasen, så overvej at inkludere dem for at opnå det, der kaldes "dækkende indekser". Igen - se Kimberly Tripps fremragende artikel - hun er SQL Server-indekseringsgudinden! :-) og hun kan forklare de ting meget bedre end jeg kan...
Så for at opsummere det:sæt din klyngenøgle på en lille, stabil, unik søjle - og du vil klare dig fint!
Marc