Guid vs INT - Qual é melhor como chave primária?

Isso foi solicitado no Stack Overflow aqui e aqui .

A postagem de Jeff explica muito sobre os prós e contras do uso do GUID.

Profissionais de GUID

• Único em cada tabela, cada banco de dados e cada servidor
• Permite fácil mesclagem de registros de diferentes bancos de dados
• Permite fácil distribuição de bancos de dados em vários servidores
• Você pode gerar IDs em qualquer lugar, em vez de ter que ir até o banco de dados, a menos que seja necessária uma sequencialidade parcial (ou seja, com newsequentialid())
• A maioria dos cenários de replicação exige colunas GUID de qualquer maneira

Contras do GUID

• É 4 vezes maior que o valor de índice tradicional de 4 bytes; isso pode ter sérias implicações de desempenho e armazenamento se você não tomar cuidado
• Pesado para depurar ( where userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')
• Os GUIDs gerados devem ser parcialmente sequenciais para melhor desempenho (por exemplo, newsequentialid()no SQL Server 2005+) e para permitir o uso de índices clusterizados

Se você tiver certeza sobre o desempenho e não estiver planejando replicar ou mesclar registros, use inte defina o incremento automático ( semente de identidade no SQL Server ).

Eu usei uma abordagem híbrida com sucesso. As tabelas contêm uma idcoluna inteira de chave primária de incremento automático E uma guidcoluna. O guidpode ser usado conforme necessário para identificar globalmente a linha e idpode ser usado para consultas, classificação e identificação humana da linha.

O id identifica a linha nesta tabela. O GUID (pelo menos em teoria) identifica essa linha em qualquer lugar do universo conhecido. No meu projeto, os celulares Android têm uma cópia estruturalmente idêntica da tabela em um banco de dados SQLite local. A linha e seu GUID são gerados no Android. Então, quando o Android é sincronizado com o banco de dados de back-end, sua linha local é gravada na tabela de back-end sem medo de entrar em conflito com as linhas criadas a partir de qualquer outro dispositivo móvel Android.

Se você estiver sincronizando seus dados com uma fonte externa, um GUID persistente pode ser muito melhor. Um exemplo rápido de onde estamos usando um GUIDs é uma ferramenta que é enviada ao cliente para rastrear sua rede e fazer determinadas classes de descoberta automática, armazenar os registros encontrados e, em seguida, todos os registros do cliente são integrados em um banco de dados central volta do nosso lado. Se usássemos um número inteiro, teríamos 7.398 "1"s, e seria muito mais difícil acompanhar qual "1" era qual.

O uso de IDs de incremento automático pode vazar informações sobre sua atividade comercial. Se você administra uma loja e usa order_idpara identificar publicamente uma compra, qualquer pessoa pode descobrir seu número mensal de vendas por aritmética simples.

A resposta de rmirabelle é o que eu faço. No entanto, para projetos de maior escala, existe um design final, onde ambos podem ser usados:

Uso: uma tabela de mapeamento de teclas

O TableA.ID é usado localmente em seu banco de dados como a chave primária e a chave a ser usada para JOINing. TableAMap.ID é igual a TableA.ID e TableAMap.UniversalID é usado apenas entre sistemas.

TableA

- ID int (PK)
- Data varchar(100)

TableAMap

- ID int (PK)
- UniversalID GUID (Indexed - nonclustered)

Os GUIDs raramente são necessários para replicação/importação/exportação de banco de dados. Assim, em vez de ter o GUID na tabela principal, onde ele ocupa 8 bytes extras por linha e onde um índice GUID será (por padrão) armazenado no mesmo volume; uma tabela separada (também conhecida como normalização) vem em socorro.

Com uma tabela separada, seus DBAs podem armazená-la em outro disco mais lento. Além disso, se o GUID for necessário APENAS para determinados trabalhos em lote, você poderá criar o índice GUID imediatamente antes de ser necessário e soltá-lo depois.

Além disso, certamente é possível simplesmente adicionar UniversalID à TableA, em vez de adicionar uma tabela de extensão como TableAMap.

Eu vejo muitas respostas típicas neste tópico sobre GUIDs aleatórios e coisas como NEWSEQUENTIALID() salvando o dia. Sim, concordo que os GUIDs de qualquer forma são bastante grandes, mas esse é realmente o único problema que eles têm. Eu vou te dizer que os GUIDs aleatórios NÃO são o problema de fragmentação que eles supostamente "provaram" ser. Provavelmente na apresentação mais heterodoxa sobre o SQL Server que você já viu, eu provo que a fragmentação Random GUID é na verdade um mito perpetuado por testes insuficientes e desinformação. Acontece que eles não são o problema... NÓS SOMOS O PROBLEMA!

Para resumir sobre como evitar a fragmentação de GUID literalmente para milhões de inserções...

1. Por causa da distribuição uniforme, quando você atinge cerca de 1% de fragmentação, está à beira de uma fragmentação massiva acontecendo na tabela em praticamente todas as páginas ao mesmo tempo. Você deve agir quando ultrapassar 1% de fragmentação lógica.

2. A ação que você precisa executar é criar espaço livre acima do fator de preenchimento. Isso significa que você NÃO DEVE USAR REORGANIZE porque não é capaz de criar páginas adicionais para espalhar o índice para criar o espaço livre acima do fator de preenchimento. Na verdade, REORGANIZE as páginas COMPACTAS até o fator de preenchimento. Em outras palavras, faz o possível para remover o máximo de espaço livre possível no pior momento possível. Em vez disso, você DEVE usar uma RECONSTRUÇÃO.

3. Acontece também que por causa da compactação, REORGANIZE realmente causa e perpetua a fragmentação. Acontece que na verdade é melhor NÃO fazer nenhuma manutenção de índice ao invés de fazer errado e a compactação do índice que REORGANIZE faz está fazendo totalmente errado porque não pode criar o espaço livre acima do Fator de Preenchimento para parar a fragmentação. Se você trabalha 24 horas por dia, 7 dias por semana ou usa a Standard Edition onde não pode fazer uma reconstrução ONLINE, aguarde um período de manutenção quando puder.

4. Além disso, REORGANIZE é anunciado como sendo muito menos intensivo em recursos do que REBUILD. Na verdade, isso não é verdade, especialmente quando você reduz o Fator de preenchimento para evitar a fragmentação, mesmo em índices não GUID.

Concordo que por causa do que nos ensinaram ao longo dos anos, tudo isso parece impossível. Aqui está o slide final de uma apresentação que fiz que mostra o histórico de um ano de GUID Clustered Indexes (veja a legenda) usando GUIDs pré-classificados como uma linha de base cada vez maior sem fragmentação, GUIDs aleatórios sem manutenção de índice e GUIDs aleatórios com 3 Fatores de preenchimento em que as reconstruções "Low Threshold" de 1% foram usadas a uma taxa de inserção de 100 MIL linhas por dia.

Aqui está um dos slides que mostram como REORGANIZE é ruim para o arquivo de log. A Linha Vermelha é a suposta linha de "Melhores Práticas" e a pequena e minúscula LINHA VERDE na parte inferior do gráfico é a Linha de reconstrução de 1% "Low Threshold".

Se você quiser ver a apresentação, por favor veja o vídeo a seguir onde eu destruo os mitos da fragmentação Random GUID e destruo a suposta "Best Practice" Manutenção de Índice que 98% do mundo cometeu o erro de usar nos últimos 22 anos. Em seguida, entenda também que as lições aprendidas sobre manutenção de índice se aplicam a outros tipos de índices.

Aqui está o link do vídeo. Como aviso para aqueles que usam fones de ouvido, eles inseriram alguns anúncios barulhentos e de ocorrência repentina nos horários das 15:00, 30:15 e 45:25 para "pagar as contas" para manter o GROUPBY.org funcionando.

Aqui está o link.

Manutenção do Índice de Artes Negras 1.2 - Guias vs. Fragmentação