290 - SQL ou NoSQL: EIS A QUESTÃO! 🤔 | theWiseDev SQL

[@frednobre2295]

Espetacular!

[@IgorfariasSk8]

Que massa! Deu uma aula!

[@otaviolemos]

Valeu, Igor: NÓIS! :)

[@pabllomartin27]

Que video bom e que livro bom, obrigado por trazer o conteúdo!

[@AntonioMarcos-qp3kw]

Não entendo como este canal só tem 32,5k de inscritos. Muito bom! Obrigado por mais este conteúdo. Ficou perfeito!

[@felipePuziol]

É por isso mesmo. Os MUITO bons, em geral, "demoram" a ser reconehecidos. Os que estouram são os mais "chamativos".

[@rwietter]

Conteúdo técnico e de qualidade sempre tem menos pessoas interessadas do que memes e hypes de tecnologia xyz.

[@otaviolemos]

Boa: valeu! 😄

[@12005914]

Gostei do vídeo, tem muitas informações relevantes. Tenho desenvolvido dezenas de aplicações utilizando bancos relacionais e até hoje não vi a necessidade de usar um noSql. Quem sabe no futuro.

[@arthuralvespsy]

Que revisão cirúrgica!! Eu estou aqui ansioso para a proxima parte, também estou lendo este livro e usando os videos para revalidar os entendimentos.

[@otaviolemos]

Arthur, obrigado! Estou com o DDIA meio em background agora porque achei o Grokking Simplicity que é mais urgente na minha produção de conteúdo. Mas não esqueci dele não e provavelmente vai sair mais vídeos dele mais para frente... :)

[@EdsonT.]

Show de ⚽

[@mateusjbarbosa99]

Magnífico, professor!

[@otaviolemos]

Obrigado, Mateus!

[@macaconerd2121]

Bom vídeo

[@gustaf_rickli]

"Se há tantas cabeças quantas são as maneiras de pensar, há de haver tantos tipos de amor quantos são os corações." - Liev Tolstói, livro Anna Karenina

[@devpaz]

Parabéns Otávio! Excelente explicação! Isso mostra cada vez mais de que devemos sair menos afobados em programar e mais em pensar como modelar. Agora a pergunta: acha que se quebra essa complexidade para seleção de qual alternativa utilizar, fazendo diagramas de UML? Grande abraço

[@otaviolemos]

Opa, nesse caso seriam diagramas ER. UML seria mais para o nível de aplicação. Veja, eu acho que quando se tem bastante experiência com modelagem e o modelo não é muito complexo, não é necessário fazer os diagramas. De qualquer maneira, quando há dúvida, o diagrama ajuda muito para discutir opções. Seria o que o Martin Fowler chama de UML as sketch. Sou bem a favor dessa abordagem.

[@yurimelo3404]

Você está fazendo um vídeo por capítulo?

[@otaviolemos]

Não é o plano mas vamos ver… 😅

[@marcelinoborges5088]

Sinceramente tenho aplicado bastante mongodb nos mais variados tipos de aplicações e os "dbrefs" ou "refs" parecem estar atendendo muito bem minhas queries em que preciso fazer "join" em docs de diferentes collections. Até sinto que tou ficando cada vez mais "analfabeto" em SQL, porque simplesmente não tenho usado há bastante tempo kkk

[@otaviolemos]

Hahah boa!

[@alexdossantosliberato4636]

Vamos falar sobre banco vetorizado?

[@otaviolemos]

Ñ sei nem o que é isso.... nunca ouvi o termo! heheh

[@fabricioaraujo7642]

Parabéns pelo conteúdo professor , queria saber uma coisa e hoje você com mais experiência desenvolvendo você recomenda um projeto começar com clean arch ou arch hexagonal?

[@otaviolemos]

Sim. Se for um projeto minimamente complexo, eu usaria Clean Arch/Hexagonal desde o começo. Claro, em algum ponto você pode simplificar e ñ fazer ID; por exemplo, ao chamar uma função de biblioteca, colocar uma dependência direta do caso de uso para a lib. Isso não impacta tanto e se precisar mudar, pode mudar depois. Bem, precisa usar o bom senso e avaliar em cada caso; mas como estrutura geral da aplicação eu acho a Clean Arch perfeita.

[@Nicolasm15inze]

Qual é esse paper Otávio? Disponibiliza pra gente, nem que seja o DOI desse cara ai

[@otaviolemos]

Não é paper, é livro. 😅 kzbin.info/www/bejne/e4nae6qthK9ki7s

[@noriller]

E agora pra complicar ainda mais, está aparecendo muita plataforma de DB que cobra por leitura de rows em vez de armazenamento. Não sei o quanto é o caso, mas parece que pode sair mais barato duplicar os dados do que normalizar entre várias tabelas.

[@mickquesado]

Esse exemplo do name e first_name no mongo daria para tratar no proprio banco com um "project" e na aplicacao continuaria name, isso na consulta.

[@Cahnisama]

Todo mundo fala que DDIA é um excelente livro, eu ouvi umas críticas em relação ao capítulo 9 em particular.

[@alexdiasdeoliveira3218]

Otávio mistura SQL, NoSQL and Tolstói no MESMO VÍDEO! Tragarm um Oscar para esse gênio! Quando teremos GK Chesterton e Dostoiévski? ;)

[@otaviolemos]

ahaha boa! :) Sou fã de ambos. Meu romance preferido é Crime e Castigo (depois de terminar o David Copperfield do Dickens vou pegar Os Irmãos Karamazov) e Ortodoxia é genial. Estou lendo as histórias do Padre Brown para meus filhos também... ;)

[@dyonatha97]

​@@otaviolemos ganhou ainda mais o meu respeito agora! Ahahahaha

[@Hunter-1984-X]

Quando o NOSQL(MongoDB) cresce muito não tem vantagem de performance e precisa fazer a gestão do schema flexível. O tamanho o DB noSQL cresceu muito de forma desnecessária.