Frederik lo resume muy bien, y eso es realmente lo que Kimberly Tripp también predica:la clave de agrupación debe ser estable (nunca cambia), siempre creciente (IDENTIDAD INT), pequeña y única.
En su escenario, preferiría colocar la clave de agrupación en la columna BIGINT en lugar de la columna VARCHAR(80).
En primer lugar, con la columna BIGINT, es razonablemente fácil hacer cumplir la unicidad (si no hace cumplir y garantiza la unicidad usted mismo, SQL Server agregará un "uniquefier" de 4 bytes a todas y cada una de sus filas) y es MUCHO más pequeño en promedio que un VARCHAR(80).
¿Por qué es tan importante el tamaño? La clave de agrupamiento también se agregará a TODOS y cada uno de sus índices no agrupados, por lo que si tiene muchas filas y muchos índices no agrupados, tener 40-80 bytes frente a 8 bytes puede hacer rápidamente un ENORME diferencia.
Además, otro consejo de rendimiento:para evitar las llamadas búsquedas de marcadores (desde un valor en su índice no agrupado a través de la clave de agrupamiento en las páginas de hoja de datos reales), SQL Server 2005 ha introducido la noción de "columnas incluidas" en sus índices no agrupados. Esos son extremadamente útiles y, a menudo, se pasan por alto. Si sus consultas a menudo requieren los campos de índice más uno o dos campos más de la base de datos, considere incluirlos para lograr lo que se denomina "índices de cobertura". Una vez más, vea el excelente artículo de Kimberly Tripp:¡ella es la diosa de la indexación de SQL Server! :-) y ella puede explicar esas cosas mucho mejor que yo...
Entonces, para resumir:coloque su clave de agrupación en una columna pequeña, estable y única, ¡y lo hará bien!
Marc