Provavelmente pela idade de cada e a fluência do inglês dos desenvolvedores de cada época em que os termos foram introduzidos. Nós apenas herdamos o "sotaque" do termo SQL dos mais antigos.
Vídeo excelente, como sempre. Comecei a tentar dar um gás pra estudar de novo, lendo livro técnico antes de dormir e vendo um vídeo seu antes de começar a trabalhar e não tem coisa melhor. Teu vídeo é muito bem explicado de forma técnica e direta e ainda é bem leve de assistir, sem causar muito desgaste mental.
Galego, muito boa essa abordagem de trazer esses comentários com a visão prática da galera e ir fazendo o match com a explicação teórica. Gostei muito mesmo disso.
Uma simplificação da decisão é a aplicação do Teorema CAP (Consistência, Disponibilidade e Tolerância a Partições): Bancos relacionais são prioritariamente CA, enquanto bancos NoSQL são prioritariamente CP ou AP. Sem P não há escalabilidade, sem C você não garante a consulta de todos os dados, e sem A você não garante se os dados obtidos são válidos. Tudo depende do que é mais importante para a aplicação. Dando aquela de chato: JSON e XML são considerados mais dados semiestruturados do que não estruturados. A estrutura está lá porque há um padrão que esses arquivos seguem, mas ela não é rígida como em uma tabela
Sobre ACID, acredito que você deva fazer um video dedicado. Por ter resumido muito, não ficou precisa sua resposta. Mas gostei do video, aprendi coisas novas
ótimo vídeo, seguindo a ideia da Order que você trouxe no vídeo, é comum (e viável) "misturar bancos de dados " ? como por exemplo ter um DB SQL para os users, ja que vamos ter um schema bem definido, e ter um NOSQL para armazenar as orders ? visto que seria mais facil armazená-la em formato JSON. faz sentido ? isso acontece no mundo real ?
É viavel sim. eu nunca trabalhei em e-commerce, então eu nunca vi pessoalmente um caso de ordens. Mas ja vi userSettings separado, cache com redis tbm tem em todo lugar. E eu ja trabalhei uma applicação que lidava com estatisticas de partidas de varios esportes em real-time. As estatisticas ao vivo iam sendo atualizadas num DynamoDB, e quando a partida acabava a gente agregava os dados e colocava num Postgres.
nunca vi mano, trabalhei com e-commerce, existia 2 formas, salvar partes dos dados na navegação(cache em json) ou criar tabela(evita perda de carrinho) aonde uma das colunas salvaria dados em json, ai na hora da finalização do pedido, era salvo no banco de dados na tabela de pedidos(usava mysql). como não pode ter erros nesses dados de comprar se usa sql, por se bem estruturados e otimos para fazer querys complexas. edit: não que não tenhas bons nosql para fazer isso, mas normalmente não se usa.
Tem um conteudo bem legal do Taborda que ele fala um pouco sobre algumas praticas de modelagem do NoSQL: ua-cam.com/video/T1Y11RiNVe8/v-deo.html Vale a pena conferir
Excelente vídeo! Creio que agora posso explicar as principais diferenças. Restou uma dúvida somente, na parte do "impedance mismatch", onde temos a questão de muitos itens e detalhes do pagamento: 1) Ter muitas tabelas no SQL e usar de "join" para junta-las em uma query é realmente um problema? 2) Ter entidades mais complexas e com muitas sub-estruturas de dados é um bom motivo para migrar tal entidade para NoSQL?
Eu já vi empresa usando mongo db com collections que possuem relações entre elas, muitas dessas relativamente complexas. Gerando queries complexas que impactava em uma pessima performance. Eu sei que o mongo tem a opção de lookup para criar essas relações na query (já que não existe FK). Alguém saberia me dizer se faz sentido usar um banco nosql desse jeito?
Provavelmente essa empresa deveria utilizar o SQL relacional ou no máximo um misto, relacional no geral + alguma coisa que mude muito ou não seja nao tenham colunas ficas utilizar NoSQL. Tipo pagaments (no relacional) ai vai ter outras tabelas ligadas a ela e um payment_details que usa uma chave com id do payment, aí no seu serviço vc faz select no payments e com o id dele faz a consulta no Mongo com este ID
Do ponto de vista mundo real, fugindo da teoria, se vai precisar fazer analytics nos dados posteriormente, use SQL, se não, use NoSQL. A resposta de falando sobre MVP é totalmente válido do ponto de vista mundo real também. Hoje em dia qualquer banco SQL escala a torto e a direito e é CAP consistent.
Pq sql ele fala com sotaque Br e nosql fala com sotaque inglês?
éssequêélle
Provavelmente pela idade de cada e a fluência do inglês dos desenvolvedores de cada época em que os termos foram introduzidos. Nós apenas herdamos o "sotaque" do termo SQL dos mais antigos.
pergunta p ele
@@leongraff7476 Pergunto nada, sou timido
Acho que todos perceberam, mas é bem melhor focar no conteudo. Meme: Ficar focando nessas coisinhas é pedir pra desenvolver TDH kkk 😂
Maluco... Explicação "técnica" de qualidade, rápida e sem bullshit. Obrigado.
Cara, só continua postando. Seu conteúdo é bem da hora
Conheci o canal pelo twitter e nem sou muito de comentar em vídeos, mas meus parabéns pelo canal! Conteúdo e formato muito bom!
Sensacional! Parabéns pelo conteúdo.
Vídeo excelente, como sempre.
Comecei a tentar dar um gás pra estudar de novo, lendo livro técnico antes de dormir e vendo um vídeo seu antes de começar a trabalhar e não tem coisa melhor.
Teu vídeo é muito bem explicado de forma técnica e direta e ainda é bem leve de assistir, sem causar muito desgaste mental.
Galego, muito boa essa abordagem de trazer esses comentários com a visão prática da galera e ir fazendo o match com a explicação teórica. Gostei muito mesmo disso.
Uma simplificação da decisão é a aplicação do Teorema CAP (Consistência, Disponibilidade e Tolerância a Partições): Bancos relacionais são prioritariamente CA, enquanto bancos NoSQL são prioritariamente CP ou AP. Sem P não há escalabilidade, sem C você não garante a consulta de todos os dados, e sem A você não garante se os dados obtidos são válidos. Tudo depende do que é mais importante para a aplicação.
Dando aquela de chato: JSON e XML são considerados mais dados semiestruturados do que não estruturados. A estrutura está lá porque há um padrão que esses arquivos seguem, mas ela não é rígida como em uma tabela
Aprendi muito, obrigado!
Cara, seu conteúdo é tão f*da que é surpreendente ser gratuito.
Tudo de bom, fera demais
Cara, parabéns pelo canal! Recebi a recomendação desse vídeo pelo UA-cam e gostei imensamente. Já me inscrevi e vou assistir o próximo!
Redis a uns anos publicou um e-book gratuito com boa parte das informações do vídeo. Me lembro de ler. "Data Modelling Patterns in Redis"
cara mais didatico que achei no youtube! incrivel.
Sobre ACID, acredito que você deva fazer um video dedicado. Por ter resumido muito, não ficou precisa sua resposta. Mas gostei do video, aprendi coisas novas
Excelente conteúdo. Vlw demais!!!
Parabens pelo conteúdo. Me ajuda demais no dia a dia.
Bacana o conteúdo!
Video muito bom. Bem roteirizado e com explicações muito claras. +1 inscrito
ótimo vídeo, seguindo a ideia da Order que você trouxe no vídeo, é comum (e viável) "misturar bancos de dados " ? como por exemplo ter um DB SQL para os users, ja que vamos ter um schema bem definido, e ter um NOSQL para armazenar as orders ? visto que seria mais facil armazená-la em formato JSON. faz sentido ? isso acontece no mundo real ?
É viavel sim. eu nunca trabalhei em e-commerce, então eu nunca vi pessoalmente um caso de ordens. Mas ja vi userSettings separado, cache com redis tbm tem em todo lugar. E eu ja trabalhei uma applicação que lidava com estatisticas de partidas de varios esportes em real-time. As estatisticas ao vivo iam sendo atualizadas num DynamoDB, e quando a partida acabava a gente agregava os dados e colocava num Postgres.
nunca vi mano, trabalhei com e-commerce, existia 2 formas, salvar partes dos dados na navegação(cache em json) ou criar tabela(evita perda de carrinho) aonde uma das colunas salvaria dados em json, ai na hora da finalização do pedido, era salvo no banco de dados na tabela de pedidos(usava mysql).
como não pode ter erros nesses dados de comprar se usa sql, por se bem estruturados e otimos para fazer querys complexas.
edit: não que não tenhas bons nosql para fazer isso, mas normalmente não se usa.
Tem um conteudo bem legal do Taborda que ele fala um pouco sobre algumas praticas de modelagem do NoSQL: ua-cam.com/video/T1Y11RiNVe8/v-deo.html
Vale a pena conferir
Obrigado Galegod, tava no dilema sobre isso ontem, abro o youtube e tem um video seu
Excelente vídeo! Creio que agora posso explicar as principais diferenças.
Restou uma dúvida somente, na parte do "impedance mismatch", onde temos a questão de muitos itens e detalhes do pagamento:
1) Ter muitas tabelas no SQL e usar de "join" para junta-las em uma query é realmente um problema?
2) Ter entidades mais complexas e com muitas sub-estruturas de dados é um bom motivo para migrar tal entidade para NoSQL?
1) não ter que abrir uma GMUD e pedir autorização do papa toda vez que precisa fazer um alter table
Eu já vi empresa usando mongo db com collections que possuem relações entre elas, muitas dessas relativamente complexas. Gerando queries complexas que impactava em uma pessima performance. Eu sei que o mongo tem a opção de lookup para criar essas relações na query (já que não existe FK). Alguém saberia me dizer se faz sentido usar um banco nosql desse jeito?
Provavelmente essa empresa deveria utilizar o SQL relacional ou no máximo um misto, relacional no geral + alguma coisa que mude muito ou não seja nao tenham colunas ficas utilizar NoSQL. Tipo pagaments (no relacional) ai vai ter outras tabelas ligadas a ela e um payment_details que usa uma chave com id do payment, aí no seu serviço vc faz select no payments e com o id dele faz a consulta no Mongo com este ID
Em alguns SGBDs atuais como PostgreSQL tem colunas de Json que funcionaria pra maioria desses casos
@@AlvesNamor Sim, exato. Usar o mongo pra projections…
Quando é melhor usar NoSQL: quando vc ja chegou no ponto de ter que salvar um JSON em um campo Char😂 e fazer a query usando LIKE Nesse campo🤣🤣🤣
Antigamente, antes de inventarem o sql, so se usavam nosql
PA DUM TSS
Kkkkkkkk
bom video
Json e XML são dados semi-estruturados.
maluko, recebi toneladas de conhecimento em databases
Do ponto de vista mundo real, fugindo da teoria, se vai precisar fazer analytics nos dados posteriormente, use SQL, se não, use NoSQL.
A resposta de falando sobre MVP é totalmente válido do ponto de vista mundo real também.
Hoje em dia qualquer banco SQL escala a torto e a direito e é CAP consistent.
Show!
Ótimo video
Isso tudo tendo sido explicado, a vida real normalmente é:
✅Quando não sei SQL
É, bora estudar. 📚
Falar pro ce que esse cara ta mais tecnico que o Akita kkkkk
me passei me passei
amigo, "Quando NÂO usar SQL", é quando eu não quiser, tá ligado? B)
EXCEL>SQL
NÓSQUEL
Conteúdo Embaçado