Vantagens e desvantagens das chaves de banco de dados GUID/UUID

Question

Já trabalhei em vários sistemas de banco de dados no passado, onde a movimentação de entradas entre bancos de dados teria sido muito mais fácil se todas as chaves do banco de dados tivessem sido GUID/UUID valores.Já considerei seguir esse caminho algumas vezes, mas sempre há um pouco de incerteza, especialmente em relação ao desempenho e URLs não lidos pelo telefone.

Alguém já trabalhou extensivamente com GUIDs em um banco de dados?Que vantagens eu obteria seguindo esse caminho e quais são as prováveis ​​armadilhas?

Answer 1

Vantagens:

• Pode gerá-los offline.
• Torna a replicação trivial (em oposição ao int, o que torna MUITO difícil)
• ORM geralmente gosta deles
• Único em todos os aplicativos.Portanto, podemos usar os PKs do nosso CMS (guid) em nosso aplicativo (também guid) e saber que NUNCA teremos um conflito.

Desvantagens:

• Maior uso de espaço, mas o espaço é barato(er)
• Não é possível fazer o pedido por ID para obter o pedido de inserção.
• Pode parecer feio em um URL, mas sério, o que você está fazendo ao colocar uma chave de banco de dados REAL em um URL!?
• É mais difícil fazer a depuração manual, mas não tão difícil.

Pessoalmente, eu os uso para a maioria dos PKs em qualquer sistema de tamanho decente, mas fui "treinado" em um sistema que foi replicado em todos os lugares, então TÍnhamos que tê-los.YMMV.

Acho que a questão dos dados duplicados é uma porcaria - você pode obter dados duplicados de qualquer maneira.Chaves substitutas geralmente são desaprovadas onde quer que eu esteja trabalhando.Porém, usamos o sistema semelhante ao WordPress:

• ID exclusivo para a linha (GUID/qualquer).Nunca visível para o usuário.
• O ID público é gerado UMA VEZ a partir de algum campo (por exemploo título - torne-o o título do artigo)

ATUALIZAR:Portanto, este recebe muito +1 e achei que deveria apontar uma grande desvantagem dos GUID PKs:Índices agrupados.

Se você tiver muitos registros e um índice clusterizado em um GUID, seu desempenho de inserção será uma merda, pois você obtém inserções em locais aleatórios na lista de itens (esse é o ponto), não no final (o que é rápido)

Portanto, se você precisar de desempenho de inserção, talvez use um INT auto-inc e gere um GUID se quiser compartilhá-lo com outra pessoa (ou seja, mostrá-lo a um usuário em uma URL)

Answer 2

@Matt Sheppard:

Digamos que você tenha uma mesa de clientes.Certamente você não quer que um cliente exista na tabela mais de uma vez, ou muita confusão acontecerá nos departamentos de vendas e logística (especialmente se as múltiplas linhas sobre o cliente contiverem informações diferentes).

Portanto, você tem um identificador de cliente que identifica exclusivamente o cliente e garante que o identificador seja conhecido pelo cliente (nas faturas), para que o cliente e o pessoal de atendimento ao cliente tenham uma referência comum caso precisem se comunicar.Para garantir que não haja registros de clientes duplicados, você adiciona uma restrição de exclusividade à tabela, seja por meio de uma chave primária no identificador do cliente ou por meio de uma restrição NOT NULL + UNIQUE na coluna do identificador do cliente.

Em seguida, por algum motivo (que não consigo imaginar), você será solicitado a adicionar uma coluna GUID à tabela do cliente e torná-la a chave primária.Se a coluna do identificador do cliente ficar sem garantia de exclusividade, você estará causando problemas futuros em toda a organização porque os GUIDs sempre serão exclusivos.

Algum "arquiteto" pode lhe dizer que "ah, mas nós cuidamos do real restrição de exclusividade do cliente em nossa camada de aplicativo!".Certo.A moda em relação às linguagens de programação de uso geral e (especialmente) às estruturas de camada intermediária muda o tempo todo e geralmente nunca sobreviverá ao seu banco de dados.E há uma grande chance de que em algum momento você precise acessar o banco de dados sem passar pelo aplicativo atual.== Problema.(Mas, felizmente, você e o “arquiteto” já se foram há muito tempo, então você não estará lá para limpar a bagunça.) Em outras palavras:Mantenha restrições óbvias no banco de dados (e também em outras camadas, se tiver tempo).

Em outras palavras:Pode haver boas razões para adicionar colunas GUID às tabelas, mas por favor não caia na tentação de fazer com que isso diminua suas ambições de consistência dentro do real (==não GUID).

Answer 3

As principais vantagens são que você pode criar IDs exclusivos sem se conectar ao banco de dados.E os IDs são globalmente únicos para que você possa combinar facilmente dados de diferentes bancos de dados.Estas parecem pequenas vantagens, mas me pouparam muito trabalho no passado.

As principais desvantagens são a necessidade de um pouco mais de armazenamento (o que não é um problema nos sistemas modernos) e os IDs não são realmente legíveis por humanos.Isso pode ser um problema durante a depuração.

Existem alguns problemas de desempenho, como fragmentação de índice.Mas esses são facilmente solucionáveis ​​(guias de pente de Jimmy Nillson: http://www.informit.com/articles/article.aspx?p=25862 )

Editar fundiu minhas duas respostas a esta pergunta

@Matt Sheppard Acho que ele quis dizer que você pode duplicar linhas com GUIDs diferentes como chaves primárias.Este é um problema com qualquer tipo de chave substituta, não apenas com GUIDs.E como ele disse, é facilmente resolvido adicionando restrições únicas significativas a colunas não-chave.A alternativa é usar uma chave natural e essas têm problemas reais.

Answer 4

Os GUIDs podem causar muitos problemas no futuro se forem usados ​​como "uniqificadores", permitindo que dados duplicados entrem em suas tabelas.Se você quiser usar GUIDs, considere ainda manter restrições UNIQUE em outras colunas.

Answer 5

Por que ninguém menciona desempenho?Quando você tem várias junções, todas baseadas nesses GUIDs desagradáveis, o desempenho irá por água abaixo, já estive lá :(

Answer 6

Um outro pequeno problema a considerar ao usar GUIDS como chaves primárias se você também estiver usando essa coluna como um índice clusterizado (uma prática relativamente comum).Você sofrerá um impacto na inserção devido à natureza de um guia que não começa sequencial de qualquer maneira, portanto, haverá divisões de página, etc., quando você inserir.Apenas algo a considerar se o sistema tiver IO alto ...

Answer 7

chaves primárias-ids-versus-guias

O custo dos GUIDs como chaves primárias (SQLServer 2000)

Mitos, GUID vs.Incremento automático (MySQL 5)

Isso é realmente o que você quer.

Profissionais de UID

• Único em cada tabela, cada banco de dados, cada servidor
• Permite fácil fusão 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 precisar ir até o banco de dados
• A maioria dos cenários de replicação exige colunas GUID de qualquer maneira

Contras do GUID

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

Answer 8

Há uma coisa que não é realmente abordada, nomeadamente a utilização aleatório (UUIDv4) IDs como chaves primárias prejudicarão o desempenho do índice de chave primária.Isso acontecerá independentemente de sua tabela estar ou não agrupada em torno da chave.

Os RDBMs geralmente garantem a unicidade das chaves primárias, e garantem as buscas por uma chave, em uma estrutura chamada BTree, que é uma árvore de busca com um grande fator de ramificação (uma árvore de busca binária tem fator de ramificação de 2).Agora, um ID inteiro sequencial faria com que as inserções ocorressem apenas um lado da árvore, deixando a maioria dos nós das folhas intactos.Adicionar UUIDs aleatórios fará com que as inserções dividam os nós folha em todo o índice.

Da mesma forma, se os dados armazenados forem principalmente temporais, muitas vezes acontece que os dados mais recentes precisam ser acessados ​​e reunidos.Com UUIDs aleatórios, os padrões não se beneficiarão disso e atingirão mais linhas de índice, precisando, portanto, de mais páginas de índice na memória.Com IDs sequenciais, se os dados mais recentes forem mais necessários, as páginas de índice ativas exigiriam menos RAM.