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

[@DevSoutinho]

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

[@Renanhuben]

Kkkkkkkkkkkk muito bom

[@felipearanha564]

que comentário mais soltinho, amei

[@darkside3ng]

😂😂😂😅

[@gustaf_rickli]

akakkakakakak, mto boa a comparação

[@cristianoseixas2417]

As aventuras de timtim 😂😂😂

[@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.

[@gabrielcamurcab]

Po, que dica sensacional! Obrigado!

[@MrExtremsX]

Acho q vc quer dizer que isso de usar o ID pode ser um vazamento de informação sensivel. Mas usar "ID na URL" não necessáriamente é uma falha de segurança

[@gabrielcamurcab]

@@MrExtremsX pse. Quando a info é mais "pública" tipo produto, post, ou algo assim sempre prefiro usar o "slug". Pra alterações administrativas, dependendo do projeto, deixo o id.

[@elgleidsonn]

Se a API é acessada publicamente, isso é considerado falha de segurança porque é fácil saber que existe um ID 2, 3, 4. Então fica fácil de explorar isso. É teu sistema dando dicas pro hacker de como explorar algo, por isso é considerado falha e um pentest decente pega isso. Mas aí vai a questão: mesmo se for uma API de uso interno, eu consideraria falha de segurança. Se, por algum motivo, alguém conseguir acessar essa API interna, facilita com que uma grande cagada seja feita. Quando se é sênior, a questão é sempre "depende" e sempre existem trade-offs. Quer tomar esse risco, e em caso de alguma falha de segunda, como alguém externo conseguiu acessar uma API de uso interno (inclua aí empregados, principalmente), tu prefere responder isso pra gerência/diretoria (stakeholders) com: - "temos um problema de performance, mas é seguro!" - "foi mal. Priorizamos performance sobre segurança" Adivinha o que custa mais pra qualquer empresa! Tanto em termos de imagem pública quanto em temos de custo de contornar o problema. Mais barato hardware mais potente do que uma imagem arruinada por "sistema atacado por hackers" nas manchetes.

[@MrExtremsX]

@@gabrielcamurcab Nem sempre da pra usar SLUG, mesmo sendo uma boa pratica SEO para certo casos. Veja, se vc tiver um estoque de peças, já não dar pra usar isso, entende? Veja o youtube, seria impossivel eles usarem slug para os videos

[@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.

[@jefperito]

Complicado, tenho 15 anos e estou trabalhando em uma B2C com milhões de usuários e qualquer coisinha que precisamos de persistência, tem que avaliar e até fazer teste de carga dependendo do cenário

[@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.

[@oqueeuseisobre]

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

[@waltwhite8126]

Acho que boa parte de quem fala que não aprendeu nada na universidade provavelmente entrou sem saber programar, saiu direto da escola pra universidade. É muito mais fácil absorver os conteúdos quando vc já tem uma boa base em programação, principalmente se já trabalhar na área.

[@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? kkkkk

[@lucasdonizeti3641]

Mas realmente o banco fica mais leve? É que até onde eu sei, as chaves primárias e os indexes melhoram a performance do banco...

[@fabiorabelo4679]

Abordagem típica de quem migrou um sistema Dbase para Sql Server...

[@RodrigoZanchetta]

@@lucasdonizeti3641 Apenas em cenarios de leitura, quando temos que fazer inserções e updates no qual não sejam de facil acesso ao index, esse processo demora muito mais por conta do banco ter de redimencionar e reorganizar os indexes, a cada index a tendencia é deste processo ser cada vez mais custoso ao banco

[@gabrielgomesch]

boa sorte amigo. ter que tankar essas decisões sem nexo baseadas em achismos é foda.

[@Adams456]

Assista o vídeo do fabio akita sobre bancos de dados, além do mais você deveria tirar essa dúvida também com seu time, é uma pergunta simples.

[@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.

[@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.

[@pedrodaniel3161]

ele é fanboy de nativo, e nunca vi ele montano nada

[@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.

[@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.

[@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

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

[@NinjaAdd]

Eu ando usando ele para coleta de dados de diagnóstico, de forma anônima, em programa desktop. Justamente por causa de ser derivado do timestamp e no meu caso é gerado do lado do próprio cliente, então quase que garante que tenham uuid únicos, mesmo sendo criados do lado do cliente. Como a coleta é anônima e consensual pelo usuário, se um dia alguém quiser tentar mudar o uuid ou coisa assim também não faria diferença nenhuma e não há quase nenhuma query para ele durante o uso, só em consulta interna depois de exportar. Atendeu super bem.

[@DavidsonAlencar]

Qual ferramenta esta utilizando para escrever na apresentação? Gostei da simplicidade para fazer algumas anotações:)

[@DavidsonAlencar]

Qualquer um que souber agradecerei ❤

[@ThiagoSouza-sz4qp]

Não sei se já encontrou, mas acho que é o excalidraw

[@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.

[@desenvolvedor-de-software]

Uma coisa que o Flickr faz para gerar IDs únicos inteiros em banco de dados distribuídos é ter um banco de dados só para gerar IDs. É o tipo de coisa que eu torceria o nariz para fazer, mas funciona...

[@charless.9139]

Artigo desnecessário, não agrega, a conclusão não sustenta a oratória. Continuem usando UUID em seus sitemas, faça aquilo que vai satisfazer o seu cliente.

[@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.

[@HandledToaster2]

Escreva teu próprio comentário, cara

[@heraldo623]

Valeu GPT

[@emotional_damage__]

Parece muito chatgpt kkkkkkkkk

[@LuizArmesto]

Esse artigo deveria ser substituído simplesmente por "Troque o UUIDv4 pelo UUIDv7"

[@bdmaxvalera]

😂😂😂😂 exatamente

[@ELSONWELLER]

E eu aqui aprendendo ainda tudo do zero nunca nem codei estou estudando sobre Gif e comandos no terminal do ubuntus...me pergunto se um dia irei saber sobre os termos que o Lucas fala no vídeo kk

[@edimachzin]

Eu costumo ofuscar IDs via aplicação (tempo real) na hora de expor publicamente, fazendo encode para expor e decode para receber. Em conjunto com um "secret". Mas nunca mexo no padrão sequencial do DB, que me parece perfeito. Será que estou fazendo alguma loucura?

[@CaiqueUnico]

Eu faço exatamente assim, e quase não vejo ninguém comentando sobre isso. Será que há uma falha que não estamos enxergando?

[@edimachzin]

@@CaiqueUnico parece que agora com UUIDv7 o problema foi resolvido. Ofuscar via aplicação tem algumas desvantagens que no meus casos nunca fizeram diferença, como uso de CPU adicional, memória... Mas falha teoricamente não existe.

[@gahfaustino]

Um dos motivos de usar o uuid é em casos de alta escalabilidade e assincronicidade, sendo assim, o lance do desempenho é mitigado pela arch como um todo. Se tu têm uma arch sync, só uma tabela, db num server só, acho que poderia usar outras coisas. Se o sistema nao for distribuido pode usar outra abordagem

[@jorgebugal]

O SQL Server tem uma função pra gerar uuid "sequencial", pra ser usado como chave primária, a newsequentialid.

[@denisschimidtdeoliveira5244]

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.

[@rubenbelem]

Vale lembrar que apesar de ser fácil correlacionar pelo nome, "Árvore B" não é árvore binária, é uma generalização da árvore binária que permite os nós terem mais que dois filhos :)

[@RodrigoFariasRezino]

Outra coisa sobre o insert, até por questão de idempotency, é uma boa gerar o UUID no cliente.

[@viniciusgabrieldossantos1745]

Tô desenvolvendo um sistema pra minha empresa e estava procurando conteúdos de UUID, pois quero implementar isso na base de dados. Além de achar um conteúdo, o Lucas Montano do canal Lucas Montano me lembrou de beber água, isso é um pai 🤌

[@gdalfovo]

Maluco fala de escala e depois mete um inteiro de 32 bits como PK. 🤦🏼 Não tem como levar esse "artigo" a sério.

[@issacohasi]

Cara, a uns 10 anos atras trabalhei numa empresa que rodavamos o SAP em oracle. O grandes DBAs criavam indices como agua. Tinha tabela que o indice tinha 200 giga e os dados eram 110 giga.

[@pigmaleao]

Isso é muito comum nos ERPs, utilizam o banco de dados pensando somente como um repositório de dados, criam campos, índices e tabelas indiscriminadamente com dados redundantes, acoplam módulos que foram desenvolvidos por fora e, para isso, criam as tabelas e colocam funções de sincronização entre tabelas. Presencio isso nos sistemas da TOTVS, os supostos "DBAs" são na verdade criadores de campos, índices e tabelas. Daí o que fazem é exigir mais recursos de infraestrutura à medida que o banco de dados infla, também mais recursos de desenvolvimento (frontend) para lidar com essa bagunça. Conclusão, para esses casos essa discussão de boas práticas no SGBD fica muito distante, esses grandes ERP repassam a conta pros clientes, um dos motivos de seus custos serem elevados.

[@isaquecruz4289]

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

[@ojoao3499]

JAVASCRIPT REAAAACCCCCTTTT

[@alisson551]

KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK

[@pypees]

Vídeo muito bom, já posso almoçar! Apesar de ter conseguido participado da live, tava na correria, agora posso rever com calma hahahahha Bom almoço pra todos ❤

[@i0i0br]

Uma vez eu usei UUID pela única razão de que assim eu consegui prevenir brute-force sem ter que implementar NADA de ACL na API.

[@fabriziocagnoni7326]

7:24 pq com incremental n da pra trabalhar com sistema distribuído ??

[@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."

[@heraldo623]

Isso é geralmente feito quando um problema real de performance surge.

[@guilhermenunes3044]

Ótimo vídeo. Uma curiosidade, estatisticamente falando, se você gerasse 1 bilhão de UUIDs por segundo, levaria cerca de 10 bilhões de anos para percorrer todas as combinações possíveis. Obs: considerando v4(128 bits)

[@Gabriel-sc3mg]

o cara falou falou no artigo e não falou nada, no final mandou um 'desculpe por existir, esqueçam o que eu disse'

[@marciobraz10]

12:31 q programa e esse ai, q vc desenhou, ficou mto bem explicado

[@rodrigodanielss]

excalidraw ponto com

[@kbarreto]

Excalidraw

[@marciobraz10]

@@kbarreto vlw

[@urmenyi]

UUID é como qualquer outro elemento de uma base de dados. Deve ser usado de forma planejada e consciente. Pessoalmente, uso “sob receita médica”, onde o bom-senso recomenda. Tarja vermelha.

[@danilomourelle]

Ah, qualquer artigo que começa vai na linha de "STOP doing this" ou "You must" eu nem leio. É certeza de conteúdo sensacionalista.

[@crimsonmegumin]

Tem um artigo um tanto quanto curioso chamado "Why HTMX sucks", escrito pelo próprio autor do HTMX XD

[@brunomello7499]

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

[@luciusstark]

Boa explicação! Como você disse: se tivermos N maior que 1, deixa de ser uma árvore binária porque a definição do binário na árvore refere-se precisamente ao fato de que cada nó pode ter no máximo dois filhos. Outro ponto que achei estranho foi a menção de 688 bits numa representação string de UUID, queria entender o raciocínio de ter chegado nesse valor.

[@HeitorGiacomini]

Usem uuid, tem muita rota q tem id para pesquisa. O usuario consegue acesso a tudo testando rota final 1,2,3,4 e assim vai.

[@vagner9090]

é só limitar com roles de acesso xD

[@Brendospdev]

@@vagner9090 E se um atacante tiver acesso às credenciais de alguém com cargo que tenha permissão? ou até mesmo o token se usar uma autorização pelo mesmo? Não usar ids sequenciais de forma externa reduz a chance de problema. Não to falando nem de usar uuid como pk, mas usar sequêncial de forma externa eu evito e toda empresa pelo qual passei evitam também.

[@rricardobs]

@@Brendospdev Se um atacante tiver o acesso às credenciais de alguém com permissão(seja token ou sessão), não será o uso de UUID que vai impedir de ver os dados que essa credencial permite, afinal de contas, se o atacante já tem esse acesso, ele já pode ver tudo que quiser seja com UUID ou Ids sequenciais. O uso de UUIDs não vai diminuir os danos causados pelo roubo do acesso. O problema nesse caso, é mais a brecha que permitiu o atacante roubar esse acesso, e não o uso de IDs sequenciais. O cuidado com os IDs sequenciais que as pessoas não entendem, é que muito dev desatento no passado permitia incrementar os ids na URL e retornar dados de usuário sem qualquer restrição, trocar por outro identificador ajudar a evitar isso, mas não é probido em todos os casos, como nosso colega avisou, ROLES podem ser usados e verificar se a entidade pesquisada por esse usuário, pertence a ele antes de retornar os dados. Resumindo, partindo do princípio que já se tem o acesso roubado, ter UUID realmente não faz diferença, pode apenas evitar que se automatize por script o scan de dados por URL, mas o acesso ele já tem.

[@leonamcruz9694]

​@@Brendospdev se o cara tem acesso ao teu sistema, pode ter certeza que vc tem um problema bem maior do que as ids.

[@Brendospdev]

@@leonamcruz9694 Sim, concordo. Mas não tira o fato de que ter ids sequenciais expostos é algo ruim. De todas as empresas e projetos que já passei, nenhuma delas deixava exposto e ou trabalhavam com uma espécie de friendly id ou uuid para expor pro mundo. Usavam sequencial, uuid ou outra estratégia para PK a depender do problema

[@ocoelhorp]

Você lendo artigos me lembra o Zambiasi lendo notícias kekw

[@Leandro-lv9zp]

Eu acho legal ele usar o topete para que as pessoas comentem no vídeo e faça vídeo ser mais recomendado

[@FelipeVidorVaz-r2f]

Lucas, que vc tá usando para desenhar?

[@LuccasrR]

big int incremental como PK + public_id usando o formato que preferir é o caminho

[@fonsecadev]

Isso tá incompleto porque mts tabelas usam hash table e nao b-tree dependendo da chave primaria

[@sedraccalupeteca5769]

Eu prefiro utilizar uuid4 agora estou pensando em utilizar o uuid7 ou ulid para serem ter id ordenável, não me imagino a trabalhar eu com id sequencial tendo que manter projectos de multitenant (com estratégia de múltiplos base dados), e até acho legal armazenar o uuid de forma legível (como string), no spring boot os uuid geram um campo em byte (por padrão) agora você converte o byte para string alí é chato.

[@vkRenan]

Só se preocupe com performance se você estiver fazendo um foguete.

[@Maisqbao]

Sempre vai depender do projeto. Já fiz um encurtador de url em que eu usei base 62 [a-zA-Z0-9-_]+ pra gerar o identificador único da url encurtada. Porém a nível de implementação, o banco de dados seguia com índice numérico e ficava a cargo da aplicação fazer a conversão entre base 62 e base 10.

[@Nero-we7cw]

Tô com uma dúvida, pra quem manja me ajuda kkk - O sistema é de agendamento de horários, porém podem ter vários profissionais. - O horário é criado na hora do profissional cadastrar os horários e dias disponíveis. - O que significa que irá existir vários horarios criados de 1 só vez, podem ser criados e deletados pelo profissional constantemente. Eu optei por um UUID como chave primária pois se fosse somente um número sequêncial, pode chegar a 100/200 ou muito mais em um só clique de 1 profissional, se ele quiser cadastrar disponíbilidade em todos os minutos de 1 dia só ele consegue (mas ele ia sofrer pra fazer isso no sistema escrevendo 1 por 1 kkk). Gostaria de saber se foi uma boa escolha.. Pra melhor entendimento vou colocar as partes principais das tabelas relacionadas... |SCHEDULING| | HOUR | | DATES | hour_id | ---- 1 : 1 id (UUID) | N : 1 | date | ______________ date | ________ | prof. _id | ___________ | N: 1 | | PROFESSIONAL | _________________ E é isso ai kkk Se tiver uma alternativa melhor... pode comentar vou dar uma olhada.

[@Nero-we7cw]

​@Albanorafael15 Valeu mesmo, acho que vou fazer assim mesmo, simples mas não tinha pensado ainda kkk. Minha solução eu vi que não era das melhores já kkkk tava pensando em ir excluindo os horários passados já porque ia gerar muitos horários mesmo, ia ficar lenta as consultas e tals. Outro ponto que eu queria era um relatório de agendamentos de cada usuário pra trazer futuramente o que já não seria possível caso eu excluisse eles.

[@candangos]

UUIDs Não serve para identificar uma linha única na tabela e mas sim serve para identificar um registro único entre diferentes sistemas, diferentes bases. Não espera ser chave primária mas sim estrangeira

[@ramonarthur2729]

então o ideal seria ter PK sequencial e FK GUID?

[@candangos]

@@ramonarthur2729 Pra ser um FK você teria que associar esse registro em outra tabela, certo? Então não é o caso, a menos que seja um registro em outra cabela. UUID fisicamente não teria relação com outro registro no mesmo banco, o vínculo teria que ser lógico feito no via programa

[@marioreisjr]

Ele usou Postgre. Queria ver o teste de performance para recuperar o registro usando o mongodb

[@cleristonlincoln2220]

ta ai, seria uma boa falar sobre multi-tenant

[@osnrjr]

Não basta truncar o UUID e concatenar com um número incremental? Ficaria leve, seguro e sem conflitos.

[@VanderleiRobertoMoretto]

Sim - faço isso! Mas não truncando! Você me deu umas ideias. Obrigado amigo, você é um amigo! Kkkk

[@_boraprogramar]

Prefiro id sequencial se for preciso usar em sistemas distribuidos é só implementar um snowflake ou algum algoritmo personalizado

[@elgleidsonn]

Pergunta: foi usado ID gerado pelo banco (sequencial ou UUID) ou gerado pela aplicação antes de inserir o registro? Gerar um sequencial é muito mais barato do que gerar um UUID. Então se i teste foi feito gerando isso pelo BD, pode ser que o tempo de inserção seja afetado pela geração do ID em si, não apenas pelo rebalanceamento da árvore que mantém a PK.

[@guimello00]

Qual é o software que vc usa para fazer as anotações e desenhos??

[@Diego-Garcia]

excalidraw

[@magnomp]

Só umas observações, no artigo quando ele fala em UUID legível certamente tá se referindo ao formato que estamos habituados a ver. O "ilegível" seria a forma binária, que é um array de 16 bytes. Trabalhar na forma binária não é nem de longe tão burocrático como vc deu a entender, em Java seria simplesmente utilizar o tipo java.util.UUID diretamente (é só não meter o .toString() no final como vc disse) e no seu código você vai lidar com instancias de java.util.UUID ao invés de String, inclusive fica mais typesafe. Quando/se isso precisar ser exibido em algum lugar aí sim converte-se para string. Em Node já não temos um tipo dedicado para UUID, aí é string mesmo, mas ainda assim qualquer mecanismo de persistência que se preze saberá converter isso para o tipo UUID nativo do banco de dados quando houver, então é sempre melhor trabalhar com UUID binário

[@candinhosilveira2047]

porque nao pode trabalhar com sistemas distribuidos com auto incremento?

[@crimsonmegumin]

também não entendi

[@claus7992]

Trabalhando com uuids, no caso de você ter que no código fazer diferentes trativas para caso receba um id, você tem uma tabela com recursos que o usuário pode acessar no seu site. No código você teria que escrever o uuid num if por exemplo para mudar as ações. Vocês acham que fica feio ficar colocando uuids no código?

[@teliiz]

Mas e se o usuário ou o que quer que seja, troque o id eventualmente? Nunca é bom colocar ids fixos, pois eventualmente podem ser alterados por qualquer motivo não aparente e aí vai quebrar a aplicação e gerar demanda no fix.. kkk já tive tabelas corrompidas e teve que mudar todo os ids 😢

[@erickrds]

E esse cabelo do Astro Boy?

[@KWKEAnonimo]

As aventuras de Timtim Dev. O cara é brabo

[@HSTechofc]

Assisti, entendi, vou continuar usando UUID

[@demetriusalbuquerque]

Tem um problema no que vc tá falando que a análise tá voltada apenas para bases transacionais e tá esquecendo as bases analíticas onde não são normalizadas e as chaves primárias são ignoradas.

[@Mamuthbr]

Brother, um dia o Sol vai apagar! Preocupar-se com isso agora, sei não ... talvez eu esteja velho mesmo. Acho que preciso me aposentar.

[@pedrocosta9986]

Isso tudo é subjetivo. Quer usar UUID num sistema centralizado? Usa, vc não está cometendo um crime. Só saiba que existe um preço a ser pago. O importante é saber qual o risco mais prejudicial para o teu sistema. É expor dados? É performance? É garantir identificadores únicos? Vc sempre terá que abrir mão de algo para ter outro.

[@MannuelVictorLimeira]

Prefiro usar o ULID, já que a segurança de previsão de sequência de ids por um agente malicioso raramente é relevante.

[@vitorgorzoni705]

Qual essa board que o lucas usou pra escrever??

[@klaycon]

Excalidraw

[@vitorgorzoni705]

@@klaycon vlw man

[@JonathanBaiak]

o negocio é criar uma tabela SQL com apenas uma coluna e salvar os dados em um JSON .. ...kkkkk

[@danjovis]

Usar UUID como chave primária é uma escolha comum entre iniciantes, pois acha que estão sendo espertos fazendo isso. Na verdade, nem deveria ser considerada como chave primária surrogada devido ao seu alto custo, especialmente em aplicações de alto desempenho. Isso é praticamente um tabu no mundo dos bancos de dados. Qualquer pessoa familiarizada com bancos de dados sabe que uma chave primária natural (do negócio) é preferível. Caso seja necessária uma chave surrogada, pelo menos deveria ser um bigint. No entanto, não vejo problema algum em utilizar UUID em outros campos.

[@ivensauro]

Oiii, as vezes no video você lê B tree e comenta binary tree, mas são arvores diferentes nego (

[@luciusstark]

@7:25 A informação que o UUID ocupa 688 bits é equivocado. A informação de ocupação de 128 bits representados num valor hexadecimal, beleza. O formato por string (representação legível), a UUID representada por 36 caracteres, onde 32 são hexadecimais (4 bits cada), 4 são hífens (para visualização) temos o seguinte: Cada string ocupa 1 byte (8 bits). Então, uma string ocuparia 36 bytes no total, equivalendo a 288 bits (36 chars * 8 bits) e não 688 bits. Que loucura! Queria entender qual foi o raciocínio para encontrar esse valor discrepante.

[@bruwyvn]

Ih alá o cara indexa pelo ID e não por data de criação, daqui a pouco tá pedindo pra usar XAMPP em produção

[@mateusfonseca988]

a área que mais cagam regras sem embasamento: T.I

[@buluf]

Sobre a cloudflare quero esse video aqui no meu bolso cade?

[@negaogamer6864]

N vou parar n tô nem aí kkkkkkk

[@deploybusiness]

Não consigo acessar a comunidade no discord

[@darlanluzo]

O começo do vídeo o artigo já passa informação errada... Cada banco tem comportamentos diferentes com relação ao tipo. Vou dar um exemplo temos um sistema em C# com banco SQL Server. Existe algoritmo específico para fazer o uuid de forma sequencial, evitando a fragmentação dos dados e inserindo na sequencia, logo a busca na arvore fácil. Detalha o uuid não é uma string. Trocamos o banco da aplicação para postgres. Nesse caso o algoritmo é outro, ai obtivemos uma alta fragmentação, sendo necessário fazer mais vacuum... Logo trocamos o algoritmo para um uuid sequencial do postgres e não teve mais fragmentação...

[@VanderleiRobertoMoretto]

Dias atrás meteram um brute force encima de um SQL server numa empresa gringa por causa disso ! Fica a dica!

[@maxonaga3962]

no postgres eu uso indices hash e o desempenho ate que ta aceitavel ate agr

[@paulocristo1]

eu uso e acredito que meu uso esta em conformidades com o a realidade . srsrsrs OBS não uso como chave primaria .

[@ByMichael.S]

Não sei pq, mas em 90% do video eu não entendo bulhufas nenhuma, e ainda gosto dms de assistir esses videoskkk

[@mldoliveira]

IUDI eu pensei em Playstation, kkkkkk

[@c0nf1gur4t0r]

Como eu disse uma vez no X: "Stop stopping people" kkkkkkkk

[@lgustavosmc]

Tem quem toca uuid em dados de series temporais.

[@WilianMaique]

use auto increment e GG, 0 erros, é numero, super rapido.

[@miltonatgoogle1140]

2:50 Voce mistura as coisas falando sempre em bits quando seria em Bytes.

[@crimsonmegumin]

Como assim? São bits. Esse UUID tem 32 números hexadecimais. log²16 = 4, então 32 * 4 = 128 Claro, se você armazenar como uma String, ai sim seriam bytes (eu inclui o dígito fixo que indica que é um v4)

[@miltonatgoogle1140]

Um Bit por de ter dois valores logicios possiveis: 0 ou 1 ( ou verdadeirou falso ), já um caracter pode ter 7, 8 ou 16 bits segundo o padrao usado. Já no caso da representacao do UUID como caracters, cada um é um byte, e cada byte tendo 8 bits se usar varchar/char mas se voce usar Nvarchar/char vai ter dois Bytes. A confusao é facil de fazer pois a representacao sao muitos parecidos, kb (k bits) e kB ( k Bytes). No teu caso espefico, a tua conta tá certa, mas seria 128 Bytes = o seria 128 * 8 = 1024 bits

[@crimsonmegumin]

@@miltonatgoogle1140 Como você disse, "na representação em caracteres", se for na representação binária, não seriam caracteres de 8 bits, mas sim números hexadecimais de 4 bits. E mesmo se fosse na representação em caracteres, seriam 256 bits (32 bytes * 8, não contando os "-") ou 288 bits (se você contar os "-") se você usasse UTF-32, onde cada caractere é 32 bits, ai sim seriam 1024 bits (32 * 32, não contando os "-") peço perdão, talvez eu esteja me enganando de qualquer forma, melhor essa discussão morrer aqui

[@gu_sperandio]

Como chama esse app que vc usa pra desenhar/escrever?

[@matheuspegorari1094]

Excalidraw

[@vncsmnl]

Qual o nome do site usado pros exemplos ?

[@MatheusGambati]

Toda essa discussão como se b-tree fosse a unica opção de index pra uuid e hash não existisse lol.

[@juniorstreichan-dev]

No Postgres tem tipo uuid

[@marcosvinicius-xt6hp]

qual aplicativo quadro é esse que ele escreve em ?

[@GustavoHenrique-ry9sf]

excalidraw

Identificadores universais ou numéricos: qual usar no projeto? Existem muitos "depende" aí hein. Em C# posso usar um UInt64, cujo tamanho de quase 19 quintilhões, de forma incremental visando "performance", e ainda usar um identificador universal como u UUIDv4 com indexado hash ou binário e propagar ele em sistemas distribuídos ou expor isto ao mundo exterior para que e as consultas também neste UUID serem um pouco melhor? Pode, mas tudo vai depender do projeto. Tudo vai depender sempre de muitos fatores. Não vai existir a resposta certa como no artigo tentou emplacar.

[@RaPaS3aCk]

Mano, enquanto ia assistindo, só me passava pela cabeça o som: - PLAYSTATION !! PLAYSTATION!!

[@zkira445]

A chave pix aleatória kkk

[@fka55iano]

Esse papo todo serve só para base relacional ou nosql tb entra no pacote?

[@upsxace]

Bases de dado NoSQL normalmente trazem seus próprios mecanismos de chave primária, então os Inserts nunca são um problema, mas a pesquisa talvez possa ser

[@GlaucoMorais]

E HashIDs?

[@Anitha95able]

Alguém sabe que software é esse que ele usa pra escrever na tela?

[@GustavoHenrique-ry9sf]

excalidraw

[@rafaelschueng]

Só usar ID e UUID juntos. Vai gastar mais ? Vai! Mas ao menos você tem um "ID externo" não existe almoço grátis.

[@isaacsouto9302]

Eu fiz assim no último projeto que fiz e atendeu super bem

[@bceg3961]

id 1, 2, 3, 4, 5...