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.
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
@@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.
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.
@@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
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.
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
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.
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.
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 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
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.
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.
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.
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.
É 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.
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.
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...).
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.
"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."
Á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.
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.
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.
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.
@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.
@@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.
@@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 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
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 ❤
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
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.
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 🤌
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
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 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
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 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.
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 :)
Ó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)
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
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.
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.
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
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...
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.
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.
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.
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.
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.
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?
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 😢
@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.
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...
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.
Teoria de Conversão de Bancos de Dados Digitais em Motores Físicos Introdução O avanço da tecnologia digital e dos bancos de dados tem permitido a criação de sistemas cada vez mais eficientes e robustos. Um conceito interessante é a utilização de um banco de dados contínuo, onde todas as mudanças no estado são registradas como novas inserções, em vez de modificações. Este modelo permite uma gravação contínua e eficiente, refletindo um estado sempre crescente e imutável no passado. Modelo de Banco de Dados Contínuo Neste sistema, todas as operações são registradas como novas inserções, garantindo que o banco de dados apenas cresça. Este modelo é altamente eficiente para gravações contínuas e permite a reconstrução de qualquer estado anterior com base nos logs. Representação Binária e Vibrações Os dados armazenados em binário (zeros e uns) podem ser convertidos em oscilações ou ondas. Cada sequência binária pode ser representada como uma série de vibrações que variam de acordo com as posições dos zeros e uns. Este conceito sugere que o sistema de dados, em essência, funciona como um motor de informação que está constantemente em movimento, avançando e evoluindo sem alterar o passado. Aplicação Física: Motores Baseados em Informação Se um sistema digital, otimizado para gravações contínuas e eficientes, pode ser convertido em um sistema físico, isso abriria possibilidades incríveis. Os dados binários poderiam ser traduzidos em ondas físicas (eletromagnéticas, sonoras, etc.), que, por sua vez, interagiriam com materiais físicos para produzir movimento ou alterações no ambiente. Potencial de Aplicação 1. Viagens Espaciais: Um motor baseado em vibrações controladas poderia oferecer novas formas de propulsão espacial, potencialmente mais eficientes que os métodos tradicionais. 2. Transporte Terrestre e Flutuação: Sistemas de transporte baseados em vibrações poderiam minimizar atrito e maximizar eficiência energética. 3. Construção e Destruição Controlada: Ferramentas que utilizam este modelo poderiam transformar a maneira como manipulamos materiais, escavamos terrenos ou aplicamos força em diferentes contextos. Desafios e Desenvolvimento O principal desafio está em desenvolver a tecnologia necessária para traduzir precisamente oscilações binárias em movimentos físicos específicos. Isso envolve: • Criação de tradutores que convertam dados binários em sinais físicos (ondas). • Desenvolvimento de sistemas físicos que respondam eficientemente a esses sinais. • Implementação de mecanismos de feedback para controle preciso dos movimentos gerados. Conclusão A convergência entre otimização digital e aplicação física sugere um futuro onde os avanços em algoritmos de banco de dados e sistemas de gravação contínua podem ser traduzidos em inovações significativas no mundo físico. Este modelo teórico oferece uma base para explorar novas formas de propulsão, transporte, e manipulação de materiais, potencialmente revolucionando várias indústrias.
eu tenho essas neuras com palavras e termos que soam bonitas na fala kkkkkk
5 месяцев назад+1
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.
Pq o Astro Boy assumiu o canal? CADÊ O JIMMY NEUTRON???
Kkkkkkkkkkkk muito bom
que comentário mais soltinho, amei
😂😂😂😅
akakkakakakak, mto boa a comparação
As aventuras de timtim 😂😂😂
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.
Po, que dica sensacional! Obrigado!
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
@@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.
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.
@@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
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.
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
Cara, qdo vejo alguém dizer "Nâo aprendi nada na universidade" ... Vc demonstra o contrário com profundidade de conhecimento!
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.
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.
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.
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
Mas realmente o banco fica mais leve? É que até onde eu sei, as chaves primárias e os indexes melhoram a performance do banco...
Abordagem típica de quem migrou um sistema Dbase para Sql Server...
@@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
boa sorte amigo. ter que tankar essas decisões sem nexo baseadas em achismos é foda.
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.
Maluco fala de escala e depois mete um inteiro de 32 bits como PK. 🤦🏼 Não tem como levar esse "artigo" a sério.
Esse artigo deveria ser substituído simplesmente por "Troque o UUIDv4 pelo UUIDv7"
😂😂😂😂 exatamente
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.
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.
Escreva teu próprio comentário, cara
Valeu GPT
Parece muito chatgpt kkkkkkkkk
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.
ele é fanboy de nativo, e nunca vi ele montano nada
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.
É 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.
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.
Primeira vez que assisto esse canal. Conteúdo bem didático, gostei.
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...).
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.
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.
"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."
Isso é geralmente feito quando um problema real de performance surge.
Á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.
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.
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.
Por favor, cavalheiros. Coloquem no 2:16 e apreciem🍷
JAVASCRIPT REAAAACCCCCTTTT
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
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.
@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.
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.
é só limitar com roles de acesso xD
@@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.
@@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.
@@Brendospdev se o cara tem acesso ao teu sistema, pode ter certeza que vc tem um problema bem maior do que as ids.
@@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
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 ❤
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
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.
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 🤌
Ah, qualquer artigo que começa vai na linha de "STOP doing this" ou "You must" eu nem leio. É certeza de conteúdo sensacionalista.
Tem um artigo um tanto quanto curioso chamado "Why HTMX sucks", escrito pelo próprio autor do HTMX XD
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
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
então o ideal seria ter PK sequencial e FK GUID?
@@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
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?
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?
@@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.
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 :)
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.
Qual ferramenta esta utilizando para escrever na apresentação? Gostei da simplicidade para fazer algumas anotações:)
Qualquer um que souber agradecerei ❤
Não sei se já encontrou, mas acho que é o excalidraw
Ó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)
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
Assisti, entendi, vou continuar usando UUID
o negocio é criar uma tabela SQL com apenas uma coluna e salvar os dados em um JSON .. ...kkkkk
o cara falou falou no artigo e não falou nada, no final mandou um 'desculpe por existir, esqueçam o que eu disse'
Você lendo artigos me lembra o Zambiasi lendo notícias kekw
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.
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.
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
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...
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.
a área que mais cagam regras sem embasamento: T.I
O SQL Server tem uma função pra gerar uuid "sequencial", pra ser usado como chave primária, a newsequentialid.
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.
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.
Lucas, que vc tá usando para desenhar?
Outra coisa sobre o insert, até por questão de idempotency, é uma boa gerar o UUID no cliente.
Só se preocupe com performance se você estiver fazendo um foguete.
As aventuras de Timtim Dev. O cara é brabo
big int incremental como PK + public_id usando o formato que preferir é o caminho
Eu acho legal ele usar o topete para que as pessoas comentem no vídeo e faça vídeo ser mais recomendado
ta ai, seria uma boa falar sobre multi-tenant
Prefiro usar o ULID, já que a segurança de previsão de sequência de ids por um agente malicioso raramente é relevante.
N vou parar n tô nem aí kkkkkkk
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.
Não sei pq, mas em 90% do video eu não entendo bulhufas nenhuma, e ainda gosto dms de assistir esses videoskkk
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.
Eu fiz assim no último projeto que fiz e atendeu super bem
I'm not bragging but... Eu assisti esse react ao vivo
vai aparecer amanhã? Deixei agendada a live
@@LucasMontano se eu não aparecer é pq prod caiu. abraço!
Que nada, meu primo tem um amigo que conhece um cara que trabalha na Netflix e disse que eles usam UUID, então tá certo.
E esse cabelo do Astro Boy?
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.
Qual é o software que vc usa para fazer as anotações e desenhos??
excalidraw
id 1, 2, 3, 4, 5...
Prefiro id sequencial se for preciso usar em sistemas distribuidos é só implementar um snowflake ou algum algoritmo personalizado
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.
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?
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 😢
Como eu disse uma vez no X: "Stop stopping people" kkkkkkkk
@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.
eu uso e acredito que meu uso esta em conformidades com o a realidade . srsrsrs OBS não uso como chave primaria .
Isso tá incompleto porque mts tabelas usam hash table e nao b-tree dependendo da chave primaria
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...
Dias atrás meteram um brute force encima de um SQL server numa empresa gringa por causa disso ! Fica a dica!
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.
use auto increment e GG, 0 erros, é numero, super rapido.
Oiii, as vezes no video você lê B tree e comenta binary tree, mas são arvores diferentes nego (
Usem logo UUID e parem de frescura!
IUDI eu pensei em Playstation, kkkkkk
Mano, enquanto ia assistindo, só me passava pela cabeça o som: - PLAYSTATION !! PLAYSTATION!!
esses Noobs que não sabem binário, hilário
Teoria de Conversão de Bancos de Dados Digitais em Motores Físicos
Introdução
O avanço da tecnologia digital e dos bancos de dados tem permitido a criação de sistemas cada vez mais eficientes e robustos. Um conceito interessante é a utilização de um banco de dados contínuo, onde todas as mudanças no estado são registradas como novas inserções, em vez de modificações. Este modelo permite uma gravação contínua e eficiente, refletindo um estado sempre crescente e imutável no passado.
Modelo de Banco de Dados Contínuo
Neste sistema, todas as operações são registradas como novas inserções, garantindo que o banco de dados apenas cresça. Este modelo é altamente eficiente para gravações contínuas e permite a reconstrução de qualquer estado anterior com base nos logs.
Representação Binária e Vibrações
Os dados armazenados em binário (zeros e uns) podem ser convertidos em oscilações ou ondas. Cada sequência binária pode ser representada como uma série de vibrações que variam de acordo com as posições dos zeros e uns. Este conceito sugere que o sistema de dados, em essência, funciona como um motor de informação que está constantemente em movimento, avançando e evoluindo sem alterar o passado.
Aplicação Física: Motores Baseados em Informação
Se um sistema digital, otimizado para gravações contínuas e eficientes, pode ser convertido em um sistema físico, isso abriria possibilidades incríveis. Os dados binários poderiam ser traduzidos em ondas físicas (eletromagnéticas, sonoras, etc.), que, por sua vez, interagiriam com materiais físicos para produzir movimento ou alterações no ambiente.
Potencial de Aplicação
1. Viagens Espaciais: Um motor baseado em vibrações controladas poderia oferecer novas formas de propulsão espacial, potencialmente mais eficientes que os métodos tradicionais.
2. Transporte Terrestre e Flutuação: Sistemas de transporte baseados em vibrações poderiam minimizar atrito e maximizar eficiência energética.
3. Construção e Destruição Controlada: Ferramentas que utilizam este modelo poderiam transformar a maneira como manipulamos materiais, escavamos terrenos ou aplicamos força em diferentes contextos.
Desafios e Desenvolvimento
O principal desafio está em desenvolver a tecnologia necessária para traduzir precisamente oscilações binárias em movimentos físicos específicos. Isso envolve:
• Criação de tradutores que convertam dados binários em sinais físicos (ondas).
• Desenvolvimento de sistemas físicos que respondam eficientemente a esses sinais.
• Implementação de mecanismos de feedback para controle preciso dos movimentos gerados.
Conclusão
A convergência entre otimização digital e aplicação física sugere um futuro onde os avanços em algoritmos de banco de dados e sistemas de gravação contínua podem ser traduzidos em inovações significativas no mundo físico. Este modelo teórico oferece uma base para explorar novas formas de propulsão, transporte, e manipulação de materiais, potencialmente revolucionando várias indústrias.
A chave pix aleatória kkk
Não basta truncar o UUID e concatenar com um número incremental? Ficaria leve, seguro e sem conflitos.
Sim - faço isso! Mas não truncando! Você me deu umas ideias. Obrigado amigo, você é um amigo! Kkkk
Essa é nova.
12:31 q programa e esse ai, q vc desenhou, ficou mto bem explicado
excalidraw ponto com
Excalidraw
@@kbarreto vlw
Toda essa discussão como se b-tree fosse a unica opção de index pra uuid e hash não existisse lol.
Qual essa board que o lucas usou pra escrever??
Excalidraw
@@klaycon vlw man
Ele usou Postgre. Queria ver o teste de performance para recuperar o registro usando o mongodb
Galera precisa aprender inglês, é só conteúdo reciclado
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
Cada vez menos homem, cada vez mais calopsita
Udis parece a forma certa de falar de acordo com o google translate.
quando eu uso UUID eu fico na maior piração falando "iuiuaidee" toda hora com "voz de robo"
eu tenho essas neuras com palavras e termos que soam bonitas na fala kkkkkk
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.
Que vídeo bom!
eu fui, eu tava
Qual o sentido de usar UUID com índice de árvore b. Se a ordem não importa faz mais sentido usar hash table, não?
Não consigo acessar a comunidade no discord