Frederik vat het mooi samen, en dat is eigenlijk ook wat Kimberly Tripp predikt:de clustering key moet stabiel zijn (nooit veranderen), steeds groter worden (IDENTITY INT), klein en uniek.
In jouw scenario zou ik de clustersleutel veel liever in de BIGINT-kolom plaatsen dan in de VARCHAR(80)-kolom.
Allereerst is het met de BIGINT-kolom redelijk eenvoudig om uniciteit af te dwingen (als u de uniciteit niet zelf afdwingt en garandeert, voegt SQL Server een 4-byte "uniquefier" toe aan elk van uw rijen) en het is VEEL gemiddeld kleiner dan een VARCHAR(80).
Waarom is maat zo belangrijk? De clustersleutel wordt ook toegevoegd aan ELKE en al je niet-geclusterde indexen - dus als je veel rijen en veel niet-geclusterde indexen hebt, kan het hebben van 40-80 byte versus 8 byte snel een ENORME worden verschil.
Nog een prestatietip:om de zogenaamde bladwijzerzoekopdrachten te vermijden (van een waarde in uw niet-geclusterde index via de clustersleutel in de daadwerkelijke gegevensbladpagina's), heeft SQL Server 2005 het begrip "inbegrepen kolommen" geïntroduceerd in uw niet-geclusterde indexen. Die zijn uiterst nuttig en worden vaak over het hoofd gezien. Als uw zoekopdrachten vaak de indexvelden vereisen plus slechts een of twee andere velden uit de database, overweeg dan om deze op te nemen om zogenaamde "bedekkende indexen" te verkrijgen. Nogmaals - zie het uitstekende artikel van Kimberly Tripp - zij is de SQL Server Indexing Goddess! :-) en zij kan dat veel beter uitleggen dan ik...
Dus om het samen te vatten:plaats uw clustersleutel op een kleine, stabiele, unieke kolom - en u zult het goed doen!
Marc