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
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
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.
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.
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 ❤
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?
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...).
Á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 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.
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.
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.
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
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
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.
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.
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.
"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."
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 😢
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 🤌
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 :)
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.
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
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.
@@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
Ó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)
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.
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
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.
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.
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.
Só se preocupe com performance se você estiver fazendo um foguete.
Před měsícem+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.
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.
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...
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.
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.
@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.
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)
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
@@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
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
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.
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.
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.
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.
Primeira vez que assisto esse canal. Conteúdo bem didático, gostei.
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 ❤
Maluco fala de escala e depois mete um inteiro de 32 bits como PK. 🤦🏼 Não tem como levar esse "artigo" a sério.
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?
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...).
Á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 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.
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
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.
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
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
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.
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.
certeza q quando o Montano espirra ele faz "Rrrrreeeact !!!"
Qual o nome do site usado pros exemplos ?
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
7:24 pq com incremental n da pra trabalhar com sistema distribuído ??
Qual ferramenta esta utilizando para escrever na apresentação? Gostei da simplicidade para fazer algumas anotações:)
Qualquer um que souber agradecerei ❤
O SQL Server tem uma função pra gerar uuid "sequencial", pra ser usado como chave primária, a newsequentialid.
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.
Qual é o software que vc usa para fazer as anotações e desenhos??
excalidraw
Ele usou Postgre. Queria ver o teste de performance para recuperar o registro usando o mongodb
Lucas, que vc tá usando para desenhar?
"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.
E esse cabelo do Astro Boy?
Não consigo acessar a comunidade no discord
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 😢
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.
Que vídeo bom!
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
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 🤌
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 :)
Por favor, cavalheiros. Coloquem no 2:16 e apreciem🍷
JAVASCRIPT REAAAACCCCCTTTT
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
O que está acontecendo com a cloudflare?
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
IUDI eu pensei em Playstation, kkkkkk
Esse artigo deveria ser substituído simplesmente por "Troque o UUIDv4 pelo UUIDv7"
😂😂😂😂 exatamente
ta ai, seria uma boa falar sobre multi-tenant
Qual essa board que o lucas usou pra escrever??
Excalidraw
@@klaycon vlw man
Como chama esse app que vc usa pra desenhar/escrever?
Excalidraw
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.
big int incremental como PK + public_id usando o formato que preferir é o caminho
N vou parar n tô nem aí kkkkkkk
Esse papo todo serve só para base relacional ou nosql tb entra no pacote?
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
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.
@@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.
Você lendo artigos me lembra o Zambiasi lendo notícias kekw
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
Ó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)
porque nao pode trabalhar com sistemas distribuidos com auto incremento?
também não entendi
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.
Alguém sabe que software é esse que ele usa pra escrever na tela?
excalidraw
Oiii, as vezes no video você lê B tree e comenta binary tree, mas são arvores diferentes nego (
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
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.
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.
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
12:31 q programa e esse ai, q vc desenhou, ficou mto bem explicado
excalidraw ponto com
Excalidraw
@@kbarreto vlw
no postgres eu uso indices hash e o desempenho ate que ta aceitavel ate agr
qual aplicativo quadro é esse que ele escreve em ?
excalidraw
Isso tá incompleto porque mts tabelas usam hash table e nao b-tree dependendo da chave primaria
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.
As aventuras de Timtim Dev. O cara é brabo
Eu acho legal ele usar o topete para que as pessoas comentem no vídeo e faça vídeo ser mais recomendado
Prefiro id sequencial se for preciso usar em sistemas distribuidos é só implementar um snowflake ou algum algoritmo personalizado
Assisti, entendi, vou continuar usando UUID
Só se preocupe com performance se você estiver fazendo um foguete.
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.
o cara falou falou no artigo e não falou nada, no final mandou um 'desculpe por existir, esqueçam o que eu disse'
eu uso e acredito que meu uso esta em conformidades com o a realidade . srsrsrs OBS não uso como chave primaria .
No Postgres tem tipo uuid
hm
Sobre a cloudflare quero esse video aqui no meu bolso cade?
E HashIDs?
id 1, 2, 3, 4, 5...
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.
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!
Essa é nova.
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.
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.
use auto increment e GG, 0 erros, é numero, super rapido.
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!
ʳᵉACT!
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?
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.
"O ks é bem legível doidão" - Fiasco
REACT! 🤧
Prefiro usar o ULID, já que a segurança de previsão de sequência de ids por um agente malicioso raramente é relevante.
@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.
ObjectId *_*
2:50 Voce mistura as coisas falando sempre em bits quando seria em Bytes.
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)
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
@@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
Tem quem toca uuid em dados de series temporais.