O que é SQL e NoSQL?
HTML-код
- Опубликовано: 16 окт 2024
- Afinal, quais são as diferenças entre uma estrutura de dados relacional (SQL) e não-relacional (NoSQL) e quais as principais vantagens de cada uma delas? Maurício Linhares explica neste vídeo!
✅ Curtiu? Saiba mais assistindo também:
➡ Como rodar MySQL com Docker?
bit.ly/mysql-d...
➡ Playlist respondendo Dúvidas gerais sobre programação
bit.ly/duvidas...
👨💻 Conheça nossa escola de Data Science: www.alura.com....
📄 Quer saber sobre as novidades do universo da tecnologia e semanas de conteúdo gratuito da Alura? www.alura.com....
🎧 Podcast Hipsters.Tech
hipsters.tech/
📲 Fique de olho nas novidades!
Instagram: / aluraonline
Twitter: / aluraonline
Facebook: www.alura.com.br
Vídeo muito bom, ótimo texto de fácil compreensão para pessoas que, como eu, estão começando nesse meu de programação e possuem várias dúvidas. Nada melhor do que assistir um vídeo de 12 + e aprender tudo que precisa.
Muito Obrigado.
Vou dar um pulinho lá no site.
Que bom que você gostou, Vittor! Obrigada pelo carinho! E pode contar com a gente na sua jornada de conhecimento! 💙
Caramba, daora ver o Linhares, até hoje só tinha escutado a voz!
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 é?
Meu cérebro não tá assimilando a voz do Linhares com a imagem 0_0
Uma coisa que me faz gostar dos bancos relacionais é o tempo em que eles estão "na ativa". São uns 40 anos desde as primeiras implementações, se não me engano. Acho massa tecnologias desse tipo, que duram tanto tempo. Ainda mais hoje em dia, com vários e vários frameworks de tudo que é linguagem.
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...
Amigo!!! Parabéns!!! Comecei assistir esperando um monte de ladainha, mas o caras conseguiram ensinar muitoooo! Informação organizada ao extremo, papo de quem conhece os primórdios e não deixou de acompanhar a evolução da tecnologia, conseguiram passar todos os requisitos para quem quer aprofunda-se em Big Data.
para o problema de mudar de NoSQL para outro NoSQL eu recomendo o uso de uma API.
nada te impede de ter 10 APIs diferentes para bancos de dados diferentes, o importante é existir uma coerência na informação e funcionalidade
Eu vejo muito "perco aqui e ganho ali" na escolha de um modelo não relacional ou relacional para um trabalho. O modelo relacional com uma 3FN fica tão limpo para trabalhar, mas quando precisa alterar algo é uma dor de cabeça eterna! rsrsrs
Ótimo vídeo, + 1 inscrito pra conta!
Seja muito bem-vindo, @glahsgafak1928! 🤩 Que bom que curtiu o vídeo, ficamos felizes por ter você com a gente nessa jornada. Vamos juntos! 💙
Saudades do Maurício... Muito tempo que não vejo vídeos dele. Grande Linhares.
Explicação muito boa pra quem está desatualizada como eu. 👍🏻
0:22 a tal da Structured Query Language a SQL
E o NOSQL, Not Only SQL.
Cara, excelente vídeo. Principalmente a parte que vocês salientam que os bancos não relacionais abstraem o aspecto não flexível dos bancos relacionais tradicionais mas a forma como os dados são tratados e interpretados ainda fica por responsabilidade das aplicações.
Que legal que você curtiu, Rodrigo! 😎
A justificativa para o uso de nosql dada nesse vídeo, no meu entender, não é o objetivo principal e a motivação principal de uso de nosql.
Se você tem problema de definição de tipos e mudança de formatos, não será o banco de dados que irá te salvar.
A estratégia dada para mudar um campo em nosql tem alternativas em SQL equivalentes.
No meu entendimento, a vantagem de armazenar documentos desnormalizados, mais ou menos do jeito que serão utilizados pela aplicação é um ponto realmente importante, de mudança de paradigmas de solução de problemas, de performance para escrita e recuperação.
Obviamente ser capaz de armazenar informações em estruturas variáveis dá uma flexibilidade tremenda em relação a bancos relacionais. Mas na prática, o que mais temos é um esquema bem definido e duradouro na maioria dos cases.
Agora inserir milhares de registros por segundo com uma performance invejável, por exemplo, só é possível porque as informações são armazenadas em posições sequenciais do disco, o que é por natureza impossível em uma base relacional.
Enfim. Precisa escrever e ler que nem louco? nosql é o caminho.
enfim "conheci" o Linhares hehe sou fã!
Vou aproveitar as férias da facu (que está sugando a minha alma) para estudar banco de dados na Alura. Vídeo excelente!
Booa, Chuck! E se precisar de ajuda, conte com a gente! 😉
Parabéns pelo conteúdo... Atualmente estou estudando MySQL, e estou amando...
Obrigado, Alexandre! Tamo junto! 😎
Obrigado , Aprendendo aqui !!
Like só pela piada ruim no final! hahahahaha. Brincadeirinha, tô curtindo cada vez mais a área de ensino de vocês. Só esperando virar o mês pra me matricular e começar a estudar pra mudar de área ao auge dos meus 34 anos.
Boooa! Valeu por conferir, se precisar de ajuda pode chamar a gente por inbox na redes sociais 💙😉
Então esse é o famoso Maurício Balboa Linhares... Fala Linhares, blz? :)
Excelente vídeo.
Só hoje que to vendo quem é o Maurício Linhares depois de uma eternidade só ouvindo a voz. O real não ta batendo com o que minha cabeça tinha criado rsrs
12:15 - acho que contar piadas de humor duvidoso é um mal da maioria dos profissionais de tecnologia. Boa, Paulo! haha
Linhareeeeeees, melhor co-host ever
Sempre ouvi a voz do Maurício no hipsters, ai hoje vejo ele pela primeira vez, deu aquele nó no cerebro kkkkkk
😂😂😂😂
Prefiro SQL tradicional porque garante que se algo errado passar pela validação do backend, o bd nao vai deixar passar. Por exemplo, se no bd eu tenho uma tabela produtos com uma coluna de numero do estoque como inteiro e no sistema backend eu seto uma string no atributo numeroEstoque do objeto Produto e ele aceitar porque o atributo da classe foi tipado como string erroneamente, o bd vai estourar erro na hora de salvar. Logo, o Sistema como um todo ficará mais amarrado, mais seguro. Eu gosto do Sistema mais amarrado. O problema é que pra mudar dá mais trabalho, mas o Sistema fica mais seguro. Mas, eu nao teria problema em trabalhar com o nosql, apenas não é minha preferência.
Esse Linhares é uma figura! Os podcasts sem ele não é hipster!
Fiquei um pouco confuso ainda entre as duas coisas. Porém, estou entrando a área agora. Irei me aprofundar.
Mas agradeço. Me deu um norte. Obrigado. Vai like.
Também curti bastante.
Bom demais o vídeo, simples e esclarecedor!
Que bom que curtiu, Mauro! Valeu pelo carinho 💙
Excelente vídeo, explicação muito boa e didática.
Mas fiquei com uma pequena dúvida: Foi dito no vídeo que uma das vantagens do NoSQL é que, numa mudança de tipo de dado, você não precisa fazer um Update gigante e caro nos dados antigos para manter a consistência. E, para que isso não cause problemas, o seu código deve cuidar dessa conversão para os dados que você lê. A minha dúvida é, isso não acaba causando mais dificuldades do que o tal Update gigante, visto que agora todas as suas entidades vão precisar ter código para verificar o tipo do dado e converter se necessário?
Digo isso por dois lados:
1 - Legibilidade do código: Já que seu código é responsável por "consertar" dados antigos, cada mudança no tipo dos dados adiciona algumas linhas de código para consertar o dado pro novo tipo, mas ainda funcionar com o antigo. Dessa forma, me parece que o tamanho dos códigos cresce indefinidamente, e sua legibilidade cai.
2 - Performance em runtime: Já que agora seu código é responsável por "consertar" dados antigos, e provavelmente ele lê dados novos com frequência muito maior que dados antigos, e esses dados novos não precisam de conserto, mas como você precisa garantir a consistência no seu código, ele vai, em todas as leituras, fazer algumas operações de verificação e conserto que, estatisticamente, são raramente necessárias.
Ou eu entendi tudo errado? 😅
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 :)
Amei isso. Muito didático.
muito bom o vídeo, estava fazendo um projeto para aprender MONGODB porem nem fazia ideia das diferenças achei q era tudo SQL mesmo
Perfeitamente explicado. Parabéns pelo trabalho.
Que bom que curtiu! Obrigada 💙
Que conteúdo foda!! Ajudou muito muito mesmo!. Valei Galera aiiii!!
PosgreSQL só da falha de conexão na hora de criar a DB, quando tento aplica-lo em meus projetos de teste. Já o MongoDB me serve perfeitamente, nunca tive problema algum!
Adorei o conteúdo, muito bem explicado! Só fiquei com uma dúvida: o SQL ainda é utilizado mesmo sendo muito antigo?
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 😉
Muito bom o vídeo!
Que bom que curtiu! 💙 Conte com a gente!
Sensacional essa risada do linhares, só ouvia no podcast
Show, vídeo sensacional
Muito bem explicado.
Muito bom
faz um video sobre big data
#Excelente!
Rodaram o .mp3 da risada do Linhares ao vivo hahahhaa
quando ele estiver sem voz, dá pra botar só a risada do podcast e é sucesso :)))
MUITO BOM!
Valeu, Gilmarcos! 💙
Vim ver o vídeo só pelo Linhares!! Se ele não desse risada no video tbm nao teria graça!! Grande abç Linhares!!!
Nada impede de aprendermos NoSql. Porém, adoro o BD com SQL.
1* Linguagem Unificada (Sistema internacional - SI.).
2* Está a mais de 4 décadas no mercado (consagrada).
3* Quer mudar algo na TABELA? Então faça um ALTER TABLE.
4* Segurança: Tanto nas validações com Front(PHP), BackEnd(Java), quanto na gravação dos dados (gravação crítica ao registrar uma transação financeira).
Por fim, a amarração dos dados/informações que o SQL faz de um objeto em relação a outro objeto.
Obrigado pelas informações passadas. 👍
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.
NOSQL, Not Only SQL.
o cenário tá bem Chik...
obrigaaaaaado caraaaaaaaaaaaaaaaaaaaa
A musica de fundo atrapalhou demais, poderiam deixar somente na abertura,dificultou acompanhar o conteúdo
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! 🙂
Exemplo de Banco de Dados NoSQL seria o Mongo DB?
Exatamente, Rafa! 😉
Esse semestre eu comecei a ter banco de dados na faculdade '-'
Parabéns galera excelente vídeo!
Fico imaginando a galera daqui 10 anos tentando migrar do NOSQL para o próximo banco..
Banco Quântico ele é e não é banco ao mesmo tempo kkk
Eu vim pelos ensinamentos e pela risada
Na sua empresa que lida com valores, estoques etc, você automatizaria com uma tabela Excel? Se quer falir sendo roubado responda sim. Se quer falir sem controle algum, diga sim ao nosql.
Pose até falir com sql, mas tem uma chance de ter controle
Valha tão no nerdBunker
Faltou o Paulo falar "Linhares, o nome é Progresi" rsrsrsrsrsrs
Como é engraçado que as vozes ganham um rosto, até então, desconhecido.
kkkkk Muito bom !!!
Como fica as relações 1:n n:m no nosql?
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.
Introdução: O que é SQL e o que não é SQL?
Fiquei confuso aí... Queria um conceito mais direto sobre o que é e como funciona cada um.
Quando é necessário muitos relacionamentos, um banco NoSql complica muito.
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...
Esse Maurício é a cara do Bruce Banner, só que mais gordinho e com sotaque nordestino hehe.
RIP nerdbuker
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.
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.
Cadê o Oracle? Kkk
Pra quem tem TDAH esse vídeo é complicado, ou presta atenção no Linhares ou na música (que deveria ser de fundo) kkkkkk
graças a deus só li esse comentário depois .. teria acabado com a minha experiência.
@@filipe977 kkkk
Obrigado pela participação, Linhares!
Só achei o vídeo muito prolixo. Vocês falaram, falaram, falaram e explicaram só 1 ou 2 conceitos
"Structured Query Language"
>>> SQL = Structured Query Language
Resumindo, continuem no SQL.
que horrível a piada do paulo KKKKKKKKKKKKKKK
NoSQL é modinha.
Change my mind.
É 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...
Achei muito falante as apresentações desta empresa.
Fiquei inseguro, não comprei o curso
Poxa, Léo! Se quiser conhecer a plataforma manda uma mensagem nas nossas redes sociais e você testa para ver como tudo funciona :)
Prefiro SQL