GUID pode parecer uma escolha natural para sua chave primária - e se você realmente precisa, você provavelmente poderia argumentar para usá-la para a CHAVE PRIMÁRIA da tabela. O que eu recomendo fortemente não fazer é usar o GUID coluna como a chave de cluster , que o SQL Server faz por padrão, a menos que você diga especificamente para não fazer isso.

Você realmente precisa manter duas questões separadas:

1. 
   a chave primária é uma construção lógica - uma das chaves candidatas que identifica de forma única e confiável cada linha em sua tabela. Isso pode ser qualquer coisa, realmente - um INT , um GUID , uma string - escolha o que faz mais sentido para o seu cenário.
   
2. 
   a chave de cluster (a coluna ou colunas que definem o "índice clusterizado" na tabela) - este é um físico coisa relacionada ao armazenamento, e aqui, um tipo de dados pequeno, estável e cada vez maior é sua melhor escolha - INT ou BIGINT como sua opção padrão.
   

Por padrão, a chave primária em uma tabela do SQL Server também é usada como chave de cluster - mas não precisa ser assim! Pessoalmente, vi enormes ganhos de desempenho ao dividir a chave primária / clusterizada baseada em GUID anterior em duas chaves separadas - a chave primária (lógica) no GUID , e a chave de agrupamento (ordenação) em um INT IDENTITY(1,1) separado coluna.

Como Kimberly Tripp - a Rainha da Indexação - e outros declararam muitas vezes - um GUID como a chave de clustering não é ideal, pois devido à sua aleatoriedade, levará a uma fragmentação massiva de página e índice e a um desempenho geralmente ruim.

Sim, eu sei - há newsequentialid() no SQL Server 2005 e superior - mas mesmo isso não é verdadeira e totalmente sequencial e, portanto, também sofre dos mesmos problemas que o GUID - apenas um pouco menos proeminente assim.

Depois, há outro problema a considerar:a chave de cluster em uma tabela também será adicionada a cada entrada em cada índice não clusterizado em sua tabela - portanto, você realmente deseja garantir que seja o menor possível. Normalmente, um INT com mais de 2 bilhões de linhas deve ser suficiente para a grande maioria das tabelas - e comparado a um GUID como chave de cluster, você pode economizar centenas de megabytes de armazenamento em disco e na memória do servidor.

Cálculo rápido - usando INT vs. GUID como chave primária e de cluster:

• Tabela base com 1.000.000 linhas (3,8 MB x 15,26 MB)
• 6 índices não clusterizados (22,89 MB x 91,55 MB)

TOTAL:25 MB x 106 MB - e isso é apenas em uma única mesa!

Mais alguma coisa para pensar - material excelente de Kimberly Tripp - leia, leia novamente, digira! É o evangelho da indexação do SQL Server, na verdade.

• GUIDs como PRIMARY KEY e/ou chave clusterizada
• O debate sobre índices clusterizados continua
• Chave de clusterização cada vez maior - o Debate sobre Índices Agrupados... de novo!
• O espaço em disco é barato - isso é não o ponto!

A menos que você tenha um bom motivo , eu diria para usar um INT IDENTITY para quase todas as tabelas de dados "reais" como padrão para sua chave primária - é única, é estável (nunca muda), é estreita, está sempre aumentando - todas as boas propriedades que você deseja ter em uma chave de cluster para desempenho rápido e confiável de suas tabelas do SQL Server!

Se você tiver algum valor de chave "natural" que também tenha todas essas propriedades, também poderá usá-lo em vez de uma chave substituta. Mas dois cadeias de comprimento variável de max. 20 caracteres cada não atendem a esses requisitos na minha opinião.