Que bom que você gostou, Vittor! Obrigada pelo carinho! E pode contar com a gente na sua jornada de conhecimento! 💙

2

logo vc se acostuma! :) nem a gente conhece a cara dele já que mora nos EUA!

também kkk

E a gargalhada

Kkk num é?

40 anos mas efetivamente pode botar bem menos, até quase 2000 via muito sistema em clipper rodando em banco de dados não relacional, até em grandes empresas do varejo, mas realmente sistemas de alta confiabilidade já usavam sim... isso Brasil, lá fora deveria ser diferente.... mas realmente sou muito mais banco de dados relacional tradicional...

Seja muito bem-vindo, @glahsgafak1928! 🤩 Que bom que curtiu o vídeo, ficamos felizes por ter você com a gente nessa jornada. Vamos juntos! 💙

E o NOSQL, Not Only SQL.

Booa, Chuck! E se precisar de ajuda, conte com a gente! 😉

Que legal que você curtiu, Rodrigo! 😎

Boooa! Valeu por conferir, se precisar de ajuda pode chamar a gente por inbox na redes sociais 💙😉

Obrigado, Alexandre! Tamo junto! 😎

😂😂😂😂

Que bom que curtiu! 💙 Conte com a gente!

Que bom que curtiu, Mauro! Valeu pelo carinho 💙

Oi, Gabriel! Não tem como dizer com exatidão o que causa mais dificuldade ou não, é muito relativo. Por um lado temos a flexibilidade de não precisar atualizar tudo de uma vez e gerar algum problema ou instabilidade no banco de dados, e podemos ir atualizando a medida que os dados forem sendo consultados, tendo em vista que podem existir dados que nunca ou quase nunca são utilizados e com isso temos a econômica de recursos tanto da máquina quando do banco de dados em si. Também precisamos levar em consideração que os banco de dados NoSQL trabalham de forma diferente com os dados, eles tem armazenamentos diferentes, colunar, baseado em documento, chave-valor, alguns priorizam uma melhor e mais rápida leitura dos dados outros o armazenamento. Em relação aos dois pontos que você citou, quanto a legibilidade de código, se for algo simples, uma mudança sutil e em apenas um dado ou campo, não será algo tão ruim para legibilidade, é algo necessário, e como o Mauricio falou no vídeo, nem tudo é vantagem, temos a flexibilidade de aceitar diferentes tipos de dados num mesmo campo e alterar caso necessário mas temos como desvantagem ter que adicionar mais código para fazer essa conversão. A questão da performance, não é um problema, tendo em vista que se fosse um banco de dados relacional (SQL) o custo para um update geral em toda a tabela seria muito grande e provavelmente se a tabela fosse muito acessada você teria uma queda no banco ou precisaria parar os acessos (o que nunca é bom para os negócios) para poder fazer a atualização. No caso do NoSQL, podemos atualizar à medida que vamos realizando o acesso aos dados e distribuindo esse peso, então vamos continuar utilizando o banco normalmente enquanto ele vai atualizando a medida que é necessário. Esperamos que essa resposta tenha te ajudado 😉

@@alura Faz sentido, muito obrigado pela resposta :)

Que bom que curtiu! Obrigada 💙

Valeu, Gilmarcos! 💙

Obs: Cuidado com esses argumentos de "Na minha época eu estudava SQL", dando a entender que SQL é coisa do passado (realmente é) e que (da a entender) o NoSql por ser uma "Linguagem nova" é melhor, ou vai substitui-lá. Cuidado com esses argumentos.

quando ele estiver sem voz, dá pra botar só a risada do podcast e é sucesso :)))

Oi, Caio! Simmm, o SQL é super utilizado mesmo sendo antigo porque é uma linguagem de consulta de banco de dados e muita gente da área precisa do SQL, seja pra fazer relatórios, análise de dados ou até mesmo pra conectar a aplicação à um banco de dados 😉

Oi pessoal! Já tem um tempinho que esse vídeo foi ao ar! De lá para cá, já alteramos o formato e edição dos nossos vídeos. Mas, de toda forma, obrigada pelo toque! 🙂

Exatamente, Rafa! 😉

Banco Quântico ele é e não é banco ao mesmo tempo kkk

Até vc fazer um jogo e de uma season pra outra ter trocentas modificações.

@@patriktolomeotti não entendi, pode explicar?

Loja de departamento, não preciso criar a coluna voltagem pra um chinelo de dedos, por exemplo. Não que o SQL não atenda, mas é uma vantagem que o NoSQL tem.

@@GabrielLopesbiutas han??

@@RafaelAmorimmeu Imagina uma tabela chamada produtos, e você vende chinelos, celulares, eletrodomésticos.... Agora, pq o produto chinelo precisa ter a coluna voltagem? Cada produto tem uma necessidade, e ficar criando coluna pra cada especificação é custoso demais.

No caso do MongoDB, ele suporta embbeded documents, ou seja, vc tem um objeto JSON dentro de outro. Ex. { Nome: Leonardo, Idade: 20, // aqui seria outra tabela chamada telefones, mas no caso do NoSQL, é um outro objeto JSON "embedado". telefones: [ { Numero: 9999999, NomeDoContato: Mãe do leo }, { n contatos .... } ] }

@@GabrielLopesbiutas obrigado. Mais uma duvida: se eu mudar o NomeDoContato para "Pai do leo", ele vai alterar o embbed novamente quando eu puxar as informacoes do Leonardo? Funciona como um join do sql?

​@@leonardosc2175 Sim, quando faz o update, ele atualiza o documento "pai", então quando buscar novamente pelo "Leonardo", virá o embed atualizado.

@@leonardosc2175 Só completando, o documento "pai" e o documento embedado, são 1 só, eles não são guardados separados, e quando faz um update no documento embedado, ele faz apenas 1 update no documento pai.

graças a deus só li esse comentário depois .. teria acabado com a minha experiência.

@@filipe977 kkkk

Fiquei confuso aí... Queria um conceito mais direto sobre o que é e como funciona cada um.

Se você usa NoSQL pensando da mesma forma que o SQL, você está usando errado. Ele não foi pensado para fazer muitos relacionamentos. Mas de fato, é mais complexo para fazer relacionamentos que SQL.

Sim, não foi pensado pra isso, como também não foi na questão de ordenação, filtragem dos dados...

Poxa, Léo! Se quiser conhecer a plataforma manda uma mensagem nas nossas redes sociais e você testa para ver como tudo funciona :)

É tendência, onda, ou Tsunami. É bom Jair acostumando.

NoSQL não vai dominar tudo.

Não vejo nenhuma aplicação prática em NoSQL que SQL tradicional não atenda. E´mais pra contrariar o que já funciona muito bem. SQL segue princípios de estruturas de dados muito bem definidos e úteis. Não vejo um lugar sequer onde usar NoSQL ao invés do SQL.

@Motivos Clay ?? "Grande encontro"?

@Motivos Clay Entendi, realmente havia ignorado o fato do BIG DATA receber informações de qualquer fonte em qualquer formato (ou sem formato). Mas assim como foi induzido no vídeo, isso tem um custo (hard, soft, $$, operacional, ...) enorme, não estou falando que não resolva ou que deva ser ignorado, mas as pessoas, principalmente iniciantes tendem a achar que uma tecnologia sobrescreve a outra, e este é mais um dos casos que não, NoSQL e SQL se integram, como dois irmãos, cada um no seu quarto, mas solucionando problemas juntos. Mas pra 99% dos problemas de hoje SQL ainda é a solução. Eles esqueceram de referencias esses dois universos: Dados Estruturados e Não Estruturados. Opinião...