Eu gostaria de construir um sistema distribuído. Preciso armazenar dados em bancos de dados e seria útil usar um UUID ou um GUID como chave primária em algumas tabelas. Suponho que seja uma desvantagem desse design, pois o UUID / GUID é bastante grande e eles são quase aleatórios. A alternativa é usar um INT ou LONG incrementado automaticamente.
Quais são as desvantagens de usar UUID ou GUID como chave primária para minhas tabelas?
Provavelmente usarei o Derby / JavaDB (nos clientes) e o PostgreSQL (no servidor) como DBMS.
postgresql
primary-key
datatypes
derby
Jonas
fonte
fonte
Respostas:
Depende da sua função de geração e tamanho das mesas finais
Os GUIDs devem ser identificadores globalmente exclusivos . Como discutido na documentação do Postgres 8.3, não existem metodologias universalmente apropriadas para gerar esses identificadores, mas o postgreSQL é fornecido com alguns candidatos mais úteis.
No escopo do seu problema e na necessidade de gravações offline , você organizou com perfeição o uso de qualquer coisa, exceto um GUID, e, portanto, não há vantagens compensatórias de outros esquemas.
Do ponto de vista funcional, o comprimento da chave geralmente não é um problema em qualquer tipo de sistema moderno, dependendo do número de leituras e do tamanho da tabela. Como uma metodologia alternativa, os clientes offline podem agrupar novos registros sem uma chave primária e simplesmente inseri-los ao reconectar. Como o postgreSQL oferece o tipo de dados "Serial", os clientes nunca precisarão determinar o ID se puderem executar uma gravação simples no banco de dados.
fonte
{Node_ID, Item_ID}que cada nó tem umNode_IDe umItem_IDque é incrementado automaticamente por nó.Mais um conselho - nunca use GUIDs como parte do índice clusterizado. Os GUIDs não são seqüenciais; portanto, se eles fazem parte de um índice clusterizado, toda vez que você insere um novo registro, o banco de dados precisa reorganizar todas as suas páginas de memória para encontrar o local certo para inserção, no caso de incremento automático int (bigint), seria apenas a última página.
Agora, se olharmos para algumas realizações de banco de dados: 1.) MySQL - chaves primárias são agrupadas, sem opção de alterar o comportamento - a recomendação é não usar GUIDs aqui 2.) Postgres, MS-SQL - você pode criar GUID como chave primária sem cluster e use outro campo como índice clusterizado, por exemplo, autoincrement int.
fonte
database would need to rearrange all its memory pages to find the right place for insertion=> Acho que não é o caso do Postgres, pois o agrupamento é opcional e as novas linhas são armazenadas sem ordem.Depende.
Sério, com tudo o que você deu até agora, isso é o mais longe que você pode ir.
Por que seria útil usar UUIDs? Por que você não usa INTs? Por que você não pode simplesmente indexar UUIDs mais tarde? Você entende o que significa ter uma lista classificada com a chave de um UUID e inserir um UUID aleatório (não sequencial) após alguns milhões de linhas?
Em que plataforma isso funcionará? Quantos discos? Quantos usuários? Quantos registros?
fonte