Ao desenhar uma API sobre Postgres ou MySQL, a pergunta "chave auto-incremental ou UUID?" surge mais cedo ou mais tarde. Eis a comparação que usámos para decidir na Toolbrik.
UUID v4 (aleatório)
- Vantagens: não revela volume de negócio nem ordem; gerado no cliente sem round-trip; impossível de adivinhar por força bruta (122 bits de entropia).
- Desvantagens: páginas de índice dispersas em b-trees (menor densidade de cache); 36 caracteres de texto.
UUID v1 (baseado em tempo)
- Vantagens: ordem temporal aproximada, útil para event sourcing ou particionamento por data.
- Desvantagens: revela a data e, consoante a implementação, o nó que o gerou. Vulnerável a ser adivinhado com um nó fixo.
IDs sequenciais
- Vantagens: índices compactos e rápidos, depuração fácil, URLs limpos (
/users/42). - Desvantagens: enumeráveis — qualquer pessoa pode percorrer o teu recurso; exigem o servidor para serem gerados; um bug de concorrência pode duplicá-los.
Recomendação prática
- Usa UUID v4 como chave primária por defeito.
- Gera os UUID no servidor se quiseres ocultar a ordem, ou no cliente para latência zero.
- Para tabelas de eventos, considera v1; para catálogos internos, uma sequência é perfeitamente razoável.
- Guarda SEMPRE o UUID como tipo nativo
uuid, nunca comovarchar, e usa-o como chave de cache.
Normalizar UUIDs de origem duvidosa
Nem todos os sistemas emitem UUIDs no mesmo formato: vais encontrar maiúsculas, o prefixo urn:uuid: de alguns padrões (WSDL, ATOM), ou strings de 32 caracteres sem hífenes. O validador de UUID aceita as três variantes, deteta a versão e a variante (RFC 4122 vs. reservada), e normaliza para minúsculas antes de guardares.
Gera quantos precisares com o nosso gerador de UUID (v4 e v1, com ou sem hífenes) e valida qualquer lista com o validador antes de a submeteres.