Executando verificação de segurança...
Em resposta a Qual o melhor tipo de ID para seu sistema? AUTO_INCREMENT, UUIDv4, UUIDv7 ou ULID?
4
maniero

Vamos repassar algumas coisas.

Autoincremento não é necessariamente um inteiro em alguns bancos de dados, inclusive pode ser usado uma fórmula própria, mas ok, entendi que quis limitar o escopo, até porque existe muito mais que 4 opções para chave primária única, por exemplo sequencial + Mac Address ou outras variações, até mesmo com identificadores mais curtos de qual máquina é, só para ficar em um que é relativamente popular (dê uma pesquisada nos ????flakes e outros com 64 bits em sequência e distribuído).

O tipo dos UIs não aleatório, é string ou numérico (considera-se bytes). A aleatoriedade não é o tipo.

A garantia de ser única do mundo não é absolutamente garantida, porém a chance de pegar duas iguais beira o impossível, podemos considerar garantida na prática.

Pode ver um pouco mais sobre o UUID, embora já esteja defasado o que tem lá continua válido.

Fácil de prever é uma característica boa e não ruim. As pessoas que acham que é ruim é porque acham que estão dando segurança, mas quem pensa assim vai acabar fazendo softwares inseguros.

É necessário um certo cuidado com UUIDv7, embora raro ele pode não dar o resultado que a pessoa espera, er por ser raro fica difícil perceber o problema (pequeno, reforço).

As pessoas tendem a dar mais importância para IDs distribuídos do que deveria. Tem casos para uso, mas em boa parte dos casos centralizar a obtenção do ID é o mais simples, eficiente e que dá menos problemas. Não faça overengineering.

S2

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).

Carregando publicação patrocinada...
1
mergulhao

Essa questão de como definir o ID sempre me deixa confuso com essas recomendações genéricas.

Entendo que escolher uma opção que não seja fácil de prever pode ser boa, como um usuário do sistema, uma transação, uma nota fiscal, por exemplo. Agora, para diversas outras informações que não precisam trafegar via URL (aliás, dados sensíveis deveriam trafegar pela URL????), o incremental não funciona muito bem?

2
maniero
  • Autor
    Autor

Não existe isso de ser fácil de prever. Quem acha que isso é que dá segurança não entende de segurança. Você dá acessa às pessoas ao que elas têm autorização para acessar, o resto não é para ela ter acesso, portanto se a pessoa prever algo e ela não pode acessar e o sistema foi feito por quem entende de segurança não há problema algum. Se ela acha que é melhor um ID longo para dificultar, está no jogo do tigrinho, até o invasor vai perder quase sempre, mas uma hora ela acerta.

Dados sensíveis só devem ser acessados por quem tem direito a isso, ponto. Se só tiver um dado e o ID dele for 1, ele só deve ser acesso ao autorizado, qualquer pessoa que tente usar 1 para acessar não vai conseguir, simples assim. Mais uma vez, segurança não é contar com a sorte, quando a pessoa fala em ser menos previsível ela já está admitindo que ela aceita que sorte a foda se a alguém tiver virado pra lua ou achar uma técnica nova que aumente as chances de acerto. Quem faz isso deveria ser proibido de fazer softwares profissionais.

É óbvio que existem casos que você precisa de um ID de acesso aberto para qualquer pessoa que o possua, mas isso costuma ser temporário e é exceção, é mais um ID de acesso do que um ID de banco de dados, ainda que seja aproveitado para isso (muitas implementações não usam o mesmo, preferem um ID para o DB e outro para expor publicamente). Reforço, não é a mesma coisa que estão falando aqui, é outro tipo de ID.

Boa parte dos IDs públicos gerais são justamente para acesso de qualquer pessoa, então não existe isso de previsibilidade nesses casos.

Se puder use um ID sequencial simples. Quase todos os sistemas podem. Até alguns sistemas que fazem cadastros de forma distribuída podem usar assim e na maioria dos casos, a centralização garante bem o funcionamento e o custo é de ter que esperar o efetivo cadastro para ter o ID no cliente que está fazendo o cadastro, o que geralmente fica na casa de poucos milissegundos, se muito, ou é possível fazer uma reserva (isso tem lá seu problema quando a pessoa desiste do cadastro, mas tem diversas soluções).

Se realmente precisa de um cadastro distribuído (poucos sistemas realmente precisam disso) naquela tabela, então precisa usar um ID gerado dentro um certo padrão. Atualmente o ULID parece ser o mais adequado para isso, mas não tenho experiência prática. Se o espaço for um grande problema pode se usar uma variação do Snowflake, mas geralmente não é uma ideia tão maravilhosa porque só tem problemas com espaço quem tem muito cadastro e o risco de colisão aumenta. Não podemos descartar, mas quanto mais complicado é o ID, mais restrições de uso ele tem, menos deve ser usado por quem tem pouca experiência com engenharia de software.

1
mergulhao

Opa, valeu pela resposta.

Agora compreendi melhor. Por mais que seja possível prever, se não tiver logado com a permissão adequada, não acessa. Simples e efetivo.

1
0
kaioodutra

Você tem um ponto — mas vale olhar o cenário completo:

IDs como UUID, ULID e Snowflake não foram inventados para complicar, mas sim para resolver problemas reais: escalabilidade, distribuição, exposição pública de dados, rastreabilidade e segurança passiva.

Se você tem um sistema local, centralizado, como uma padaria ou ERP interno, usar AUTO_INCREMENT (1, 2, 3...) faz total sentido. É simples, direto, performático, e o próprio banco garante integridade.

Mas se você pensa em crescer...

Quando seu sistema começa a se expandir — seja com APIs públicas, microsserviços, recursos abertos como rastreios e compartilhamentos — a previsibilidade dos IDs se torna um vetor real de exploração.

Mesmo sem vazar dados sensíveis diretamente, um atacante pode:

  • Mapear /pedido/1, /pedido/2, /pedido/3... por brute force;
  • Descobrir quantos registros existem no sistema;
  • Levantar padrões internos (quem compra mais, horários, status etc.);
  • Fazer scraping contínuo de dados públicos;
  • Criar até serviços paralelos não autorizados, sem usar sua API, apenas explorando a previsibilidade do padrão de URL.

E isso tudo sem quebrar sua segurança — só explorando sua arquitetura.

IDs aleatórios mitigam esse risco

Usar ULID, UUIDv7 ou até hash público ajuda a:

  • Evitar enumeração simples (não dá pra saber o "próximo");
  • Forçar uso da API oficial, com autenticação e limites;
  • Desacoplar lógica interna do acesso externo;
  • Reduzir a superfície de scraping automatizado.

E o argumento do "espaço"?

O custo de armazenamento de UUIDs ou ULIDs é irrelevante para 99% dos sistemas modernos. Se seu sistema não roda com dezenas de milhões de requisições por minuto, isso nem deveria ser uma preocupação.

Conclusão prática

  • AUTO_INCREMENT é perfeito para sistemas internos, fechados e simples.
  • IDs aleatórios fazem mais sentido quando:
    • o sistema está exposto ao público;
    • há risco de scraping ou indexação não autorizada;
    • a arquitetura envolve microsserviços e alta escala;
    • você quer desacoplar o ID do comportamento interno.

Um ID previsível pode virar um endpoint público involuntário.
E nesse momento, o controle do seu sistema já não é mais só seu.

3
maniero
  • Autor
    Autor

Já está respondido no meu comentário anterior, isso é quase um hoax que se espalhou. Claro que tem algum mérito no que disse, mas a maior parte disso é algo que só se vivencia quando o sistema é todo errado, é uma rolha para tapar um buraco na represa, conserta o buraco.

Eu poderia citar diversos sistemas dos mais conhecidos que não fazem isso e estão bem. Inclusive, apesar da distribuição necessária porque é um dos 5 sites de maior tráfego do mundo, precisam de bem menos servidores doque as pessoas imaginam, mais por causa do espaço do que pelo processamento, usam um sistema sequencial (repito, mesmo distribuído), previsível e não tem problema de segurança, além de ter apenas 8 bytes (já que recebem perto de bilhão de novas informações por dia). Mas lá tem engenheiros de verdade, não que aprenderam por receita de bolo. Tem muitos casos. E eles fizeram isso porque o custo geral do uso de um ID em PK de 16 bytes era proibitivo, com dados que comprovavam isso, não especulação. Nem vou entrar no mérito que quase toda distribuição feita é desnecessária. Tem exemplo de site que já foi dos 30 mais acessados do mundo que não tinha.

Existe uma diferença quando o ID é usado para outra coisa que não seja controle do banco de dados, esse é outro assunto completamente diferente e por não ser PK não é tem o mesmo tipo de problema.