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).

mergulhaoontem

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?

manieroontem
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.
mergulhaoontem
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.