9:57, vou mandar tudo pra nuvem e vao falar q e encriptado entao ta seguro, mas dps vao te encher o saco dizendo que sua cloud ta cheia pra voce fazer o upgrade do pacote kkkk
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
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...).
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.
Eu precisei reescrever a API de Acordo de Dívida de um banco digital. E foi bem parecido: desligaram COMPLETAMENTE o aplicativo até que o rewrite estivesse completo. Mas isso porque uma das razões do rewrite era de medida de segurança. Então, por 3 meses, o banco ficou com o serviço que significava 20% da receita completamente fora
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.
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.
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.
Não sou da área de programação mas sou de exatas e concordo com tudo que foi dito! Faço curso de Física e os melhores professores que tive foram aqueles que me ensinaram a pesquisar sobre os assuntos. Evidente que a didática conta também, mas uma frase que coloquei na minha cabeça depois de fracassar na minha primeira faculdade é de que 'Sou eu que estou fazendo o curso na faculdade e não é ela que está fazendo por mim!'. Se não sentar a bunda na cadeira e estudar 95% das vezes sozinho, o negócio não vai pra frente!
Cara, de coração, muito obrigado. Esse vídeo me serviu muito, e compreendo que muita gente precisa entender isso. Esse ponto de vista quebra a perspectiva e a expectativa de todo iniciante em programação, ocasionados por um processo comum que todos eles possuem, mas nem todos eles compreendem. A partir disso, pude não só entender como programação funciona, mas também, entender o quão comum é esse problema.
O bom do java é que enquanto o netbeans abre da tempo de: buscar os filhos na escola, tomar banho, levar a esposa pra fazer compras, e quando você voltar vai ter terminado de carregar. Por isso dev java é feliz, curte mais a vida.
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.
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.
Eu tentaria fazer 2 tabelas kkkk, e fazer os horarios de 10 em 10 min, ou 5 em 5. Depois cadastrava esse id na tabela de profissionais. E apresentava para cadastro 2 selects de hora e min. Dá para salvar uma lista separada por vírgula com os ids ou fazer uma terceira tabela horario_profissional.
Já passei por reescrita, e é um desafio grande. No meu caso as metodologias ágeis foi um ponto crucial para o sucesso do projeto. Sistema muito grande, legado muito antigo com muitas incertezas. Tínhamos que fazer entregas parciais que fossem transparente para os usuários. E quando aparecia alguma nova demanda evolutiva tinha que se decidir se poderia esperar até o ponto onde pudesse ser desenvolvido apenas no novo, se poderia ter uma solução paliativa no antigo ou se era urgente ou crítico e precisaria desenvolver nos dois e duplicar os custos da demanda. No final, apesar de aumento de custo e prazo por conta dessas situações e de outras, finalizamos e superamos a expectativa dos clientes/usuários.
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.
"a maioria das pessoas armazena uuid em formato legivel" cara... de onde veio isso? Qual DBMS popular que nao tem UUID nativo em formato binario? Pra que diabos alguém usaria string em uma chave primária fora por ignorância?
@@LucasMontano bem isso - quem ta gerenciando DBs e não lê binário - pls. Mas sério, dá tranquilo pra salvar o campo em binário mesmo e usar string quando for exportar dados ou gerar logs. São aplicações bem diferentes.
Que bobagem. ID incremental não vai consertar problema de desempenho nenhum. Se preocupe com o tamanho dos teus dados, não das chaves. UUIDs minimizam conflitos de recursos e minimizam chances de abuso da tua aplicação. Usem UUIDs.
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 😢
Tem uma implementação do nhibernate que eles dão uma solução para os UUIDs que são randomicos, seguindo uma data/hora do sistema e uma base para gerar os UUIDs. Para ver essa ideia pode-se pesquisar por GuidCombGenerator que irá cair na implementação deles
