só dizer “Stop Using UUIDs” é uma péssima dica

✅ Torne-se membro para obter aulas técnicas exclusivas comigo:

Fontes:

✅ Meu site parece que foi feito por um DEV backend né?! Mas lá tu encontra tudo que precisa saber sobre o que tenho feito e onde estou:

✅ 𝗢𝗦 𝗠𝗘𝗟𝗛𝗢𝗥𝗘𝗦 𝗩𝗜𝗗𝗘𝗢𝗦 𝗗𝗢 𝗖𝗔𝗡𝗔𝗟

▸ 3,700,000 requests do MrBeast na API do X (eu tentei e não foi barato)

▸ Programação realmente é muito difícil?

▸ DEV Precificando Projeto tipo Netflix (bem simples)

▸ OpenAI choca o mundo +1 (mas Sora não é sobre gerar videos)

▸ IA que utilizo & a mentira da Gemini (Nova IA do Google)

[DevSoutinho]

Pq o Astro Boy assumiu o canal? CADÊ O JIMMY NEUTRON???

[elgleidsonn]

Uma dica importantíssima, principalmente pros novatos:
Se tu for usar um ID sequencial, pelo amor de Deus, nao exponha esse ID como uma referência externa!
Isso é considerado uma falha de segurança.
Quer usar um sequencial como PK do banco? Vai fundo! Bancos relacionais te dão isso de graça. Mas use um UUID, ou alguma outra opção, como referência externa!
Nada de "POST/PUT /blabla/{referenciaExterna}" onde a referenciaExterna é um sequencial.
Hackers vão adorar explorar isso no teu sistema.
Facilmente pego por qualquer pentest decente.

[Richsan]

Cara em qse 7 anos trabalhando como backend da pra contar nos dedos de uma mão cenários de uso que a performance de escrita ou custo de armazenamento importava em algo.

[felipe.lorenz]

O dev evita usar UUID argumentando que aumenta o tamanha do banco de dados no disco e fica criando coluna tipo TEXT! Ou VARCHAR(255) sem avaliar a real necessidade to tamanho.

[FeltexBr]

Parabéns pelo vídeo. Isso acendeu uma idea de comparar o desempenho entre o uso de UUID x IDs em banco relacionais x não relacionais como MongoDB.

[AdrianoWead]

Falando em bancos de dados, tenho uma treta interna aqui. Uso de banco relacional SEM usar os recursos de FK do banco, controlando a integridade unicamente por software. Motivo? Defendem que o banco fica mais leve, é mais performático se o SGBD não tiver que lidar com o FK. E a pergunta que não quer calar é, mas um banco relacional não serve justamente para garantir o relacionamento?

[oqueeuseisobre]

Cara, qdo vejo alguém dizer "Nâo aprendi nada na universidade" ... Vc demonstra o contrário com profundidade de conhecimento!

[matheusvictorhenrique]

É o Johnny Bravo da bolha tech.



Um problema que o UUID como chave primaria pode trazer é a perda de performance em relacionamentos, mas pra esse problema se pode utilizar um BigInt como chave primaria e um UUID como candidata, podendo fazer com qua sua aplicação só precise receber o uuid do registro para fazer buscas, mantendo as vantagens de ter um id auto increment.

[MrSaitam]

O título do artigo "Stop Using UUIDs in Your Database" pode ser considerado clickbait, pois utiliza uma afirmação categórica para atrair a atenção do leitor, embora o conteúdo do artigo apresente uma análise equilibrada sobre as desvantagens e os contextos apropriados para o uso de UUIDs.

Sobre a utilização de UUIDs em APIs REST, eles são recomendados devido à sua capacidade de garantir a unicidade global, evitando colisões entre diferentes sistemas e facilitando a integração distribuída. No entanto, é importante estar ciente das implicações de desempenho no banco de dados, como discutido no artigo.

[leoinacioo]

Da para usar BigInt em sistemas distribuidos tambem, mas exige um certo trabalho. Uma técnica conhecida é voce ter um servidor de geracao de id separado. Esse servidor gera numeros inteiros com auto_increment. Obviamente voce nao quer esse servidor sozinho como unico ponto de falha do seu sistema, entao voce replica e por exemplo coloca dois servidores la, um gerando ids pares e outro gerando ids impares com um load balancer na frente.

Vale lembrar que voce nao tem ordenacao garantida nesse design.

[jackpalaro]

Primeira vez que assisto esse canal. Conteúdo bem didático, gostei.

[Lemure_Noah]

UUID deveria ser usado quando se necessita de um ID único, para ser FK consistente através de vários DBs. Nessa hora uma PK com INT pode não resolver. Mas para "tamboretes de dados", uma PK INT pode ser melhor saida.

[nivaldobrasil]

sabe o q é estranho? usar int e não int sem sinal. Perde-se metade do tamanho com números negativos q não serão usados.

[luancardosolc]

Legal que o Lucas não é fã boy de tecnologia. Critica o que tem que criticar, elogia o que tem que elogiar, isso é muito bom. Por mais que uma tecnologia seja boa, nunca será perfeita e sempre poderá ser substituida, se não agora, no futuro quando sai uma evolução que a supere.

[VanderleiRobertoMoretto]

Existe o V7 - ele resolve muitos dos problemas da v4, já que faz melhor uso do prefixo de timestamp, pois é parcialmente sequencial graças ao uso de uma fração de tempo acima da casa dos bilhonésimos de segundo. Sendo na prática indexável e mantendo a capacidade de unicidade e melhorando muito insert e search - que era o gargalo principal da v4!
Mas o problema maior é no mau uso do UUID - não se deve usar ele como chave primária e indexador (isso é um assunto para outra conversa...).

[isaquecruz]

Por favor, cavalheiros. Coloquem no 2:16 e apreciem🍷

[wgwalisongomes]

Eu uso os dois nos meus projeto 😅😅😅. Uso as chaves id inteiro para relacionar as tabelas e o UUID quando preciso expor esse registro publicamente, exemplo: /user/2 (terrível para segurança), então faço /user/uuid

[weslleyjuann]

"Posso estar errado, mas penso que cada modelo de negócio poderia implementar um algoritmo próprio para a criação de PK (Primary Key). Por exemplo, se tenho um negócio que emite notas fiscais, quais são as chances de termos duas entidades com o mesmo nome, CPF ou CNPJ criando uma conta ao mesmo tempo? Se as chances forem muito baixas, talvez criar um hash com essas informações diminuiria a quantidade de bytes em comparação com o UUID, mas não ficaria tão pequeno quanto apenas o CPF ou CNPJ, por exemplo. A criação de algoritmos personalizados para problemas específicos poderia resolver muitas questões. A questão é se existe tempo e recursos financeiros para isso. É um trade-off; quanto mais eu delego minha responsabilidade de resolver um problema para uma biblioteca ou solução pronta, mais exposto a problemas futuros eu fico caso minha aplicação escale."

[brunomello]

Árvores B+ não são árvores binárias.

EDIT, agora que to no PC e consigo digitar melhor:

Árvores B ou B+ são dois tipos de árvores com N filhos, onde N é um parâmetro de configuração da árvore que dita o número de elementos em cada nó. O número de elementos está fortemente relacionado ao número de filhos: uma árvore com N elementos tem N+1 filhos. Então, sim, se tivermos uma árvore B (ou B+) com N=1, então temos uma árvore binária, mas esse raramente é o caso para a aplicação de índices de banco de dados.

Além disso, como dito no vídeo e no artigo, árvores B/B+ são auto balanceáveis, ou seja: sempre que houver uma inserção/remoção, a árvore se balanceia "para cima" para garantir que a altura é a mesma em todas as ramificações. Uma árvore B/B+ nunca cresce para baixo, ela cresce para cima, dividindo seus subnós e botando a raiz para cima.

Sobre a diferença entre árvores B e B+, são duas basicamente:

1. árvores B armazenam dados tanto em nós internos quanto em nós folhas, já árvores B+ armazenam dados apenas nas folhas (os nós intermediários armazenam apenas "chaves fantasia" utilizadas na tomada de decisão de qual nó seguir na hora da busca)
2. árvores B+ tem suas folhas linkadas (como uma lista encadeada), permitindo maior desempenho para acessos sequenciais.

[denisschimidtdeoliveira]

O problema é que hoje em dia vejo muitas pessoas usando UUID em bancos centralizados, o que não faz sentido. Parece que virou padrão, sendo q o padrão nesse caso seria usar BigInt.
Agora pra banco de dados distribuídos, como o Lucas disse, que precisa ter uma unicidade entre as tabelas do bd aí faz sentido usar UUID.
Pra mim a regra é simples, se dá pra usar BigInt, use-a (default), mas se não é possível, use UUID.