Sql manual ou ORM nada funciona se a pessoa não souber o que esta fazendo.

Eu vim do Delphi e tudo precisava de SQL. Desde o início dos estudos tinha SQL. Nunca consegui entender um programador que não sabe SQL.

Rodrigo, vou acrescentar mais alguns pontos que acho importantes na discussão: Eu apenas trabalho com SQL puro. Programo com algumas frameworks de PHP, como por exemplo o Laravel, e continuo a preferir usar Raw queries do que usar o Eloquent ORM ou o Query Builder. Porquê? Eu desenvolvo muitas aplicações que têm que dar resposta ao Regulamento de Proteção de Dados e em que os dados ficam encriptados com AES na base de dados. Por exemplo o Eloquent ORM não dá qualquer tipo de suporte a essas funcionalidades. Além do mais, sempre que necessito verificar se os dados estão entrando corretamente no sevidor, eu preciso correr queries de SQL, uma vez que necessito desencriptar a informação que está lá guardada. Resumindo: Se você sabe SQL, vai estar a salvo em qualquer situação e linguagem. Se você domina um ORM, pode acontecer que só seja aplicável a determinado projeto e linguagem e que, num momento de mudança, você tenha que aprender outro ORM e não saia desse ciclo. SQL "for the way" sempre.

Realmente, a comparação é mesma com o CSS e o Bootstrap. Já vi muita gente que viveu anos em cima de Bootstrap e hoje não consegue centralizar uma div no CSS.

Parece que esse vídeo foi para mim!!! rsrs Essa semana fiquei 2 dias travado tentando apenas transformar uma consulta complexa que eu tinha em SQL para ORM!! Depois de perder 2 dias de desenvolvimento o que foi que eu fiz??? Deixei o SQL que já estava funcionando lá e fui seguir minha vida. rs

Excelente vídeo, me senti muito melhor. Digo isso pq tenho uma idéia totalmente negativa quanto a ORM, e achei que era o único com essa impressão, mas lendo os comentários, vi que não estou sozinho kkkkk.

Grande Branas, sou adepto do modelo Híbrido, como tudo no mundo da tecnologia depende muito de escopo , ORM as vezes pode ser o melhor e por vezes pode afundar seu Projeto ou até mesmo Aumentar seus custos. Mas em resumo acredito que o Modelo Híbrido dependendo do cenário seja mais indicado. Ganha -se produtividade sem perder performance conforme a necessidade.

Todas as empresas em que trabalhei tinham bancos de dados complexos e consultas com muitos joins. Escrever o SQL na mão foi a melhor opção. Houve tentativas de colocar um ORM, mas nunca deu certo.

Oi Rodrigo, concordo com seu ponto de vista… Trabalho dando manutenção em um monolito bem complexo em sua arquitetura, sem uma primary key específica, e várias interligações… só conhecendo bem SQL para conseguir êxito… não descobri nenhum ORM para dar este suporte

Eu vejo que a principal vantagem do ORM é a portabilidade de banco. Comigo mesmo já aconteceu duas vezes da empresa migrar do mysql para o postgre, e por estar usando um ORM, corretamente, não precisou de nenhum refactor de querys nos projetos. Já vi também muitos DBAs falar que ORM gera querys ruins, mas isso não é culpa do padrão ORM, e sim da ferramenta que gera query ruins, é como dizer que node é lento porque você já viu varias apis em node com respostas lentas. A culpa não é do node, e sim da api que foi mal feita.

Boa discussão! Eu particulamente sou adepto do modelo ORM com suporte a raw queries para consultas mais complexas.

Desse cara tá em outro nível. Nível internacional.

Acredito que seja interessante para qualquer um que use alguma abstração de alto nível, também entenda o que está acontecendo em alguns níveis abaixo. Os ORM são uma mão na roda para uma série de casos, inserções, atualizações, mapeamento de dados do banco com entidades de código. Mas para relatórios, por exemplo, onde performance e volume de dados são cruciais, escrever o SQL puro é bem melhor. Mas você só vai saber isso entendendo o alto e o baixo nível.

Concordo plenamente. Em alguns momentos pode-se perder muito tempo e tornar muito complexo fazer tudo via ORM. O híbrido ao meu ver é o melhor caminho. Usar query builder (Knex por exemplo) pode dar muita produtividade no uso de SQL.

Equilibro é a palavra. No projeto onde eu trabalho atualmente a nossa equipe utiliza ORM mesclado com SQL puro. Utilizamos o ActiveRecord do Rails e a experiência tem sido muito produtiva. Onde faz sentido fazer a query manual nós o fazemos, caso contrário utilizamos SQL. Depende do contexto e se faz sentido, não podemos nos prender a conceitos e fechar a escopos apenas por acharmos que é o ideal quando muitas vezes existem outras alternativas que se encaixam melhor naquele cenário.

Excelente! Faz anos que também abandonei ORMs. No máximo uso um query builder, para facilitar uma paginação no Oracle, por exemplo.

Excelente video !!! Eu quando comecei estava muito perdido, não entendia muito bem o porque das coisas e com o passar do tempo eu tive a oportunidade de trabalhar com SQL puro na raiz, e posso dizer que meu nível de conhecimento aumentou muito, com isso eu acho que não é muito bom partir diretamente para os ORM's se antes não tiver uma base de conhecimento em SQL para entender oque ocorre por baixo dos panos porque quando pegar um problema de maior complexidade para resolver esse conhecimento inicial é extremamente necessário

Fantástico!!! Excelente provocação!!!

Parabéns pelo video Branas, show de bola.

Eu passei por um caso em que a empresa tem um sistema legado que era um pesadelo para aplicar uma ORM. Então foi trabalhado em C# uma estrutura de interfaces de repositório, em que as funcionalidades antigas foram aplicadas por SQL e as inovações do sistema por Entity Framework. Dessa forma tudo funciona como um relógio.

Muito bom mesmo! Parabéns, Rodrigo.

Top Branas!!! Passei por essas situações também!

Cara.. mil vezes fazer manualmente as consultas em SQL - mesmo que complexas - do que (como já aconteceu comigo) perder dias tentando adaptar algo que o ORM não fazia, mergulhado em documentação, conseguir fazer uma consulta pesada de 2 minutos, quando no SQL saía em poucos millisegundos. ORM facilita, mas quando agarra, ninguém desamarra.. daí vc fazendo na mão tá tudo no controle.. dependendo da complexidade da consulta, pede uma view pro DBA e vai nela na mão só usando where's tranquilo. Usei Entity e Dapper e não me acostumei. Na faculdade foi a mesma coisa. Tinha a calculadora de gráficos vetoriais, mas o manual dela era tão extenso, que eu usava só pra fazer continhas. Era tão complexo aprender plotar cálculos mais avançados naquela josta 48G+ que eu fiz a maior parte na mão mesmo.

Já tem alguns anos que tive uma longa experiência com NHibernate e C#, um projeto relativamente grande que foi cancelado poucos meses antes do lançamento devido a uma complexidade crescente que o NHibernate adicionava ao desenvolvimento, na época você tinha que usar o XML ainda para fazer o mapeamento das classes, porém chegou em uma etapa do projeto que quanto mais complexidades adicionávamos de lógica de negócios mais overhead a aplicação ganhava, também não tínhamos boas soluções para várias queries que fazíamos pois elas eram lentas se comparadas por exemplo a um simples sql no banco. Também tive muita dificuldade de usar o NH em toda a sua plenitude, parece que os problemas que vemos na comunidade deles nunca são os nossos problemas e nunca achamos respostas o suficiente para resolver tudo. Resultado foi a lata do lixo, daí pra frente usamos um modelo híbrido caseiro porém com grande funcionalidade e compatível com nossas necessidades até hoje. Parabéns pelo vídeo e pelo levante da discussão ORM x SQL, isso sempre me martelou na ultima década. rs.....

Uma vez ouvi um episódio do Database Cast onde falaram que as consultas geradas por ORM às vezes davam uma raiva nos DBAs rsrsrs. Eu tinha um certo conflito interno, entre essas duas abordagens pois pensava que escrever SQL na mão era antiquado, mas vendo seu vídeo e a sua conversa com o Léo da Cod3r fiquei mais tranquilo, pois sempre preferi escrever SQL na mão para ter um controle melhor da consulta. Valeu xará

Trabalho em uma empresa que 90% das consultas são feitas com ORM. Hoje estamos com problema de performance e estamos migrando aos pouco para SQL.

Concordo plenamente, use ao favor, muitas consultas, relatórios a performance em SQL puro e bem maior.

Grande Branas, achei muito pertinentes suas ponderações. Show de bola!

Boa discussão. Cheguei a conclusão de que quando começamos projetos (principalmente usando agile), começamos pequeno e é difícil ver uma necessidade de ORM logo de começo, a simplicidade do SQL aumenta muito a produtividade. Quando o projeto cresce e se torna um pouco mais complexo, a simplicidade de usar SQL puro aparece novamente. Entre um estágio e outro, usar ORM soa uma decisão arriscada pra mim. Hoje em dia também vejo a comunidade de software menos focada em orientação a objetos que no passado, logo esse tipo de mapeamento faz até menos sentido em muitos cenários de hoje (linguagens focadas em tipos mais simples, tipagem fraca e dinâmica e etc..)

Cara, gosto muito do seus vídeos e eu nem sou progrmador, sou analista de dados então uso SQL todos os dias junto com python e R, tenho aprendido muito com você. Valeu!!

Excelente, Branas. Eu prefiro me comunicar direto com o DB e fazer bons testes de integração para garantir que tudo esteja OK. Minha opinião é de que frameworks ORM só devem ser utilizados para a equipe (que não tem experiência com o DB) ganhar um certo tempo na construção do projeto, mas o quanto antes deve ser removido do sistema para reduzir a superfície de eventuais problemas e otimizar a performance. Como sempre digo, para cada versão de DB há diversas versões de um mesmo ORM com dezenas, talvez centenas de bugs a qual o sistema fica exposto. PS: O melhor de usar ORMs são os recursos para execução de migrations.

Opa Rodrigo beleza? Bem que o próximo vídeo poderia ser sobre, "Fazendo integrações com N APIs utilizando NodeJs", mais pelo lado de utilizar um serviço de filas talvez, Abraço

Concerteza Branas. Eu compartilho da mesma ideia. Quando falamos de sistema, e o que vamos utilizar, e falo sempre depende

Excelente vídeo!!! E eu mesmo tenho tendência a não usar ORM nenhum, geralmente uso query builders ou SQL mesmo, mas eu entendo as vantagens e desvantagens de cada um.

Fiz algumas partes do projeto do meu trabalho usando ORM EntityFramework para CUD (Create Update e Delete) e o Read fiz via Query SQL na unha pq eu queria ter total controle sobre os selects... resumo: mesmo sendo leve da pra perceber nitidamente a demora de 2 segundos a mais do que feito full SQL.

Concordo plenamente com você Branas. Já tive que usar orms e não tive boas experiências, para crud ele é ótimo, mas para qualquer coisa mais personalizada prefiro o sql que por si só já é muito poderoso, não vejo necessidade da adicionar mais complexidade e ainda perder desempenho. Sem falar que na maioria dos casos conforme o projeto cresce a produtividade diminuí.

Criamos um software ERP do zero usando ORM. Precisamos migrar para SQL puro para corrigir problemas sérios de desempenho e ganhar facilidade na manutenção e publicação. Com SQL puro hoje é bem mais cômodo fazer as manutenções.

Belo ponto de vista para refletir. Nunca tinha pensado desta forma. Excelente vídeo!

é uma discussão que deve ser bem enfatizada e nunca pode sair de foco .. eu gosto de usar ORM, facilita MUITO a vida na hora de desenvolver mas precisamos sempre entender que facilidade não quer dizer que é sempre a melhor opção, saber conversar e ajustar o que precisa é sempre a melhor saída para termos um sistema robusto, leve e que gere um baixo custo de servidor ..

Nossa Branas, vivemos as mesmas angústias rsrs..... muitas vezes passei por situações onde parti para escrever o sql, pois estava muito custoso fazer o hibernate fazer o que eu precisava... rsrs..... fora que com criterias muito complexos, manutenção tbm fica mais difícil... obrigada pelo vídeo 🙏👏

Eu já tinha esbarrado com outro vídeo seu há um tempo e não dei atenção. Estou aprendendo node + react e já desenvolvendo um projeto. Estava utilizando o Prisma. Parei e comecei a correr atrás do 'pg' justamente porque o prisma não conseguiu trabalhar com uma tabela recursiva. Estou atualizando alguns cadastros para sql até mesmo para aprender e fixar conhemento.

A principal vantagem de usar ORM é a facilidade de fazer queries usando funções. Na minha equipe tenho uma estagiária que nunca mexeu em BD nem sabia de SQL, então não pude usar SQL manual nem um Query Builder. Ela gostou muito da abordagem e com o tempo ensinei a ela SQL, pra ela foi muito satisfatório usarmos o Sequelize, quando contei essa minha opção levando em consideração o nível de conhecimento dela, os olhos dela brilharam pq não pensei apenas em mim e sim nela também. Outra vantagem de usar ORM é ter funções "seguras" que montam a query sem possibilidade de erro de sintaxe

Fala Branas! Massa essa sua abordagem, levando em consideração várias situações e experiências. Eu mesmo escrevi muito código SQL quando trabalhava com uma ferramenta de geração de relatórios e era muito legal ver as consultas sendo otimizadas por conta de um join ou uma sub consulta reescrita. A pouco tempo, quando resolvi me aventurar no JS e agora no TS, tenho usado muito ORM, mas em algumas situações, uso consultas SQL mesmo, sem muito rodeio, por ser muito mais prático pra escrever, por ser mais claro também do que um código feito usando o ORM e com toda a certeza mais performático, porque já foi testado antes de estar no código :) Na minha opinião, quanto mais o desenvolvedor entender SQL, melhor vai ser para ele entender quando usar o query builder ou então consulta SQL pura mesmo o/

Show, tbm penso assim, trabalhando com .Net. Sempre uso ORM pra CRUD, quando é uma consulta com mais relacionamento o melhor é otimizar sua consulta no SQL puro mesmo

Ótima explanação...essa ótica de um substituir o outro não vinga, fica muito mais objetivo quando se coloca os pontos críticos e como estes são resolvidos de forma ágil e segura. Com certeza absoluta, o SQL te dá muito mais poder, logicamente porque já estaríamos pulando uma camada, justamente a do ORM.

Hoje estou utilizando uma abordagem diferente dos ORM que é o Prisma, você modela o seu banco para um schema definido por ele contendo as models (Tabelas), e ele mesmo consegue realizar as abordagens específicas para cada model dentro do seu schema (insert, select, etc.). E pra mim está sendo sensacional 👍

Sempre tive essa mesma visão que você. Sempre me neguei a usar ORM, porque para mim fazer o SQL é muito mais performático e inteligente, principalmente para o perfil de sistema que desenvolvo, normalmente grandes e complexos. No meu ponto de vista, o único ponto ruim na prática de não usar ORM é futuramente ter que trocar o banco de dados do sistema. O ORM já faria esse "translate" da query quase que de forma automática nesse caso. A grande questão é que dependendo do perfil de sistema, de fato deixa de fazer sentido usar ORM, principalmente pela complexidade que ele começa a gerar. Na minha visão, bem pragmática por sinal, ORM é uma muleta; até serve para coisas mais simples e práticas, mas atrapalha muito mais quando falamos de consultas melhor estruturadas, legíveis e performáticas. Sem contar que são tantos ORMs no mercado, que praticamente em cada estrutura de projeto vai exigir uma nova curva de aprendizado para aquele ORM específico.

Comigo foi o inverso, comecei com .Net usando o conector SQL nativo do C#... Aí conheci o Entity Framework que é o ORM mais famoso dessa tecnologia... Porém eu tinha muita dificuldade em fazer joins e etc, então eu usava apenas ele, mas quando eu consegui aprender SQL... Meu amigo abria o SQL Server e já ativava o Capslock 😎

Concordo! Porém, realmente vai de contexto para contexto. Pois o que eu mais vejo são ambientes empresariais pressionando por resultado sem se comprometer com performance e aí realmente acaba sobrando o ORM como opção que em muitos casos é melhor, pois é mais fácil/rápido de se implementar

Gosto de mesclar. ORM ajuda muito nos relacionamentos, principalmente N:N onde você não precisa se preocupar com attach/dettach/sync nas tabelas pivot (o que pra mim é algo chato de fazer na mão, não difícil, mas chato rsrs). Gosto também dos hooks que eles oferecem, principalmente os de persistência. Porém, para queries mais complexas onde exige-se consultas mais "finas", prefiro usar o query-builder ou um raw-query para obter maior performance. Já vi ORM fazer WHERE IN com milhares/milhares de registros no IN e a query acabar gerando locks e onerar o banco, onde um JOIN foi beeem mais performático. É isso, hibrido pra mim é o caminho.

Realmente, não há bala de prata em ORM... Analisar especificamente cada caso e aplicar o que for melhor para RESOLVER o problema! Boa abordagem, parabéns!

Fala meu amigo, show de bola, vale muito a pena avaliar o todo! Eu como DBA gosto muito da ideia de fazer o cada um tem de melhor, ORM pode ser sim um grande inimigo do banco de dados, não tem jeito, mas o melhor é conseguir sair da CAIXA e avaliar cada caso e fazer da melhor forma e as vezes o SQL nativo pode sim ser a melhor solução. Uma reflexão que gostaria de deixar aos teus seguidores, que devem ser a maioria desenvolvedores, avaliem o que o ORM está enviando ao banco de dados (SQL gerado) pois ele pode estar fazendo muito mais que o necessário, aí aonde começamos a ter problemas de performance. Abraços Capin

JSON foi lançado no PostgreSQL 9.2 em 09/2012, porém somente na 9.4 em 12/2014 com o JSONB a coisa ficou linda... ainda temos os dois datatypes cada um com sua utilidade

eu trabalho com hibernate/jpa mas tem horas que eles mais atrapalham que ajudam, não minto acho ótimo rabalhar cos os cascades da vida, salvar ou remover os objetos com uma linha de código, mas quando o negócio são queries, muitos joins ai o negócio complica, tem que usar uma abordagem mista

Cara, minha experiência é que para crud padrão ou consultas com até uns 10 joins, me atendeu muito bem e fez a implementação do sistema fluir muito mais rapido... outra coisa.... Se usar bem os query builders, você não fica preso a banco de dados... é fácil migrar de mysql apra postgres, por exemplo (que foi que que precisei fazer). Eu usava muito SP... e foi um inferno pra migrar quando fazia isso....

Concordo com você Rodrigo, para cruds acredito que ORM sejam imbatíveis, mas quando saímos disso na maior parte das vezes sql pura será a melhor opção.

problema é fazer os desenvolvedores parar de usar orm sempre estão pensando em crud mesmo quando não é preciso

Minhas colocações: 1 - Você usou banco relacional como se fosse um MongoDB, através de colunas JSON, teoricamente. Olha como da pra fazer as coisas, adaptar. Por isso nossa area é legal pra quem tem cabeça aberta. 2 - Nunca imaginei que Hibernate ja estava por aí em 2003. 3 - Eu vim de suporte/infra, onde sempre trabalhei com SQL pras análise de problemas, instalação de SGDBs, pra vir pra area de dev. Então sempre preferi trabalhar com SQL mesmo, por ter esse domínio. No meu mundo Java/Kotlin com Spring eu tenho o Spring JDBC. Que seria um meio de campo entre os dois, SQL puro e ORM. Tenho mapeamento direto numa Entity que vem de uma Query SQL escrita mesmo.

Ao meu ver o principal ponto que você tocou foi o seguinte: "Combinar ORM E SQL puro", tudo vai da necessidade!

Rodrigo e a todos, a vida é dura para quem é mole. Se você substituir o SQL para ter uma vida mais mole, no dia que precisar ter controle da parada, para resolver o problema, ai a vida vai ficar dura.... Eu, so uso SQL na veia, as vezes da trabalho? Dá. Mas tenho a parada na mão. E quanto mais você trabalha, mais você fica safo, e as coisas acabam ficando fáceis. Abraços.

Vi essa treta no twitter e os comentários! Como estou iniciando no SQL fico calado. Tenho realmente um grande interesse em JS e como ele trabalha com grande volume de dados.

Boa Branas, é isso mesmo. No mundo real o ideal é usar um ou outro dependendo da situação. Em projetinho de curso de programação ORM é muito lindo, indo pro mundo real a historia é outra. Mas você não acha que Query Builders como o Knex é quase o melhor dos 2 mundos? Acho relativamente fácil criar consultas um pouco mais complexas (com joins e agregadores) com o Knex.

Volta, pfvr a gravar e a dar aula.😢😢😢

Belíssima abordagem Branas! Quem vem do Java e começa com Javascript sente muita falta dos ORMs mas com o tempo nós entendemos e sentimos os benefícios do SQL puro!

. Tudo blz Branas?!? Muito legal esta discussão. Em meados de 2006 (com .NET 2 ainda), eu estava em um projeto com ORM ECO Framework e tivemos alguns "percausos" até entender certinho o que realmente fazia sentido para o nosso contexto naquela época. Bom, no final das contas, para a escrita (insert, update, delete) utilizávamos este ORM (em quase totalidade das vezes) e também evolve da base de dados, mas majoritariamente, utilizamos SQL "na unha mesmo", cheguei a utilizar com certa frequência o Profile do SQL Server justamente para analisar o I/O das queries e descobrimos que para cenários mais "ricos" de relacionamentos, tínhamos mais performance sem ORM. Foi muito interessante esta experiência e até hoje sempre que posso (e que principalmente faz sentido) utilizo esta visão crítica e analítica sobre criação de queries manualmente (sem ORM)! .

Acho que cada um com sua necessidade. montei uma arquitetura de Jobs, onde ler e escreve dados no erp e salva log nas tabelas locais, para ler e inserir dados no erp usei jdbc com sql puro, para as tabelas locais hibernate.

Eu lembro que um pouco depois de começar a trabalhar profissional com programação surgiu o hibernate… era um frisson todo mundo comprando “Hibernate in Action” livro com mais de 500 páginas eu lembro que achava horrível perder tempo descobrindo como fazer algo que com SQL seria muito mais fácil, mas na época eu era bem novo no mundo da programação simplesmente achava ruim, mas aceitava e seguia fazendo meu trabalho. Hoje mais de 15 anos passado, não gosto de ORM, respeito quem utiliza, mas não aceita perder uma hora estudando esse tema, migrei de tecnologia diversas vezes durante a carreira e certamente ou continuar migrando e sabe o que sempre estava lá ? … ele msm SQL!!! já ORM mudou de línguas mudou o jogo…

No Laravel faço muito isso, a maioria senão todas as consultas simples uso o Eloquent e funciona muito bem, porém em consultas complexas vou sem medo no SQL.

Me identifiquei muito... Há um tempo fiz um trabalho acadêmico com node + querybuilder e achei que na hora de fazer os DAOs foi pouco produtivo, então agora estou fazendo meu TCC com C# e Entity Framework e está sendo muito mais complexo, nessa linha que comentou de ficar pensando sei como é isso no sql mas e aqui no framework

Utilizando ou não um ORM eu normalmente criou a consulta de maneira nativa e depois transpilo para o ORM (HQL, Criteria e etc). Vejo problemas de desempenho constante pelo mal uso do ORM e prefiro o bom e velho SQL!

Show demais Branas 👏 👏 E um Query builderzinho ? Tá ali no meio termo rsrs

Achei interessante a forma como você encara as ORM. Devem ser usada, porém para contextos específicos. Usar porque empresa x ou y usa não é justificativa, tem de saber se a sua equipe sabe lidar com tão tecnologia. Parabéns, Rodrigo Branas como sempre postando conteúdo com qualidade.

Fala Branas! Posso utilizar um ORM para consultas simples, e fazer "no braço" as que possuem mais complexidade, ou o interessante seria uma única abordagem? Valeeus!

Uso ORM(Eloquent do laravel + sem o laravel) num sistema com um monte de SQL puro, dados altamente relacionais e não vi um caso onde fosse melhor usar SQL puro, quem fala de problema de performance com ORM não se preocupou em tratar as chamadas e debugar as queries geradas, a navegação na sintaxe de objetos também é muito mais limpa que puxar uns 100 valores nomeados direto de um resultSet só

Acho que esse que é o problema, me vejo na msm situação, não manjo muito do sql, melhorar um plano de execução de fato...saber um índice melhor etc... Porém acho que o simples se torna complexo, um sistema ele era simples se torna complexo, vários joins vários relacionamentos e o dado cresce exponencialmente ...e assim que surge as tretas

Utilizei Hibernate até um ano e meio atrás. Por causa destas dificuldades com consultas migrei para o SQL, mas optei por um framework DSL chamado JOOQ que possibilita fazer consultas de forma tipada e com todas funcionalidades que o banco oferece, é como escrever em SQL nativo mesmo, e por ser tipado consigo fazer muitas refatorações com segurança.

ótima abordagem e me deu certo medo, sinto pequena dificuldade em ambas as partes você me indica a procurar me aprofundar mais ou alguma ORM do lado do node ali ja consegue atender minhas expectativas?

Sempre fui do Back-End e sempre preferi usar o original e não recorrer a frameworks, tanto pela questão de velocidade quanto pelo uso 100% da tecnologia com a única limitação, ser a própria tecnologia e não o “meio do caminho” (framework). Porém, quando tive que “colocar o pé” no Front-End e tive que usar CSS, não tinha tempo suficiente pra aprender o necessário e acabei optando por usar o Bootstrap, e em um determinado momento, mesmo para uma coisa que não era complexa, ele não supriu a necessidade e naquele momento fez falta saber CSS puro, pois como qualquer framework, haverão certos recursos que não estarão presentes no framework e/ou precisarão de um update futuro, contando que não haverão bugs. Hoje em dia prefiro sempre aprender a tecnologia “pai” por assim dizer, principalmente se não é uma tecnologia tão amplamente difundida, a ponto dos frameworks fazerem o papel quase que 100% igual ao original. É preciso muito cuidado ao escolher fazer uso de uma tecnologia “mais fácil” em um projeto, pois lá na frente, o que foi uma solução, pode vir a ser a coisa que vai travar o seu projeto e atrasar novas demandas. É sempre bom ponderar, mas se puder, opte pela tecnologia original. E mesmo que a demanda seja urgente, busque aprender e evoluir na tecnologia “pai” enquanto desenvolve o produto/solução utilizando um framework. Pode ter a certeza de que o seu eu do futuro agradecerá e o tempo gasto para consertar problemas, será menor.

Não tenho e ate prefiro. Exemplo, só por agora, na ultima versão do Entity Framework, que saiu uma forma de você numa única viagem ao DB conseguir fazer um update em algum registro. Antes você tinha que buscar o item no banco, fazer a modificação e aí salvar as mudanças. No SQL, desde sempre, basta fazer um update where x... Uma viagem, muito mais simples. p.s.: Acho que foi no Postgres 9.1 ou 9.2 que saiu a coluna json.

acho que para quem está começado o orm terá uma curva de aprendizagem mais fácil que slq puro. e a sim depois de pelo menos fazer o crud com orm tentar fazer o msm com sql puro.

Cara, ta ai, eu senti isso quando resolvi testar ORM, eu me senti menos produtivo, pareceu que só adicionei uma camada a mais de complexidade. Parece que para o simples, ,e melho escrever mesmo.

Eu sinceramente acho que a pessoa usar um ORM sem a mínima noção de SQL, não faz o menor sentido. O Java com SQL realmente é um porre pra fazer aqueles códigos junto com as queryes, mas depois de pronto vc tem um controle lindo, rs.

Os dois!

Acostumado sempre com ORM, quando precisei escrever SQL diretamente tbm sofri kk hoje em dia os frameworks e ORM's deixa o programador mal acostumado

ORM pode ser mais produtivo ao longo de muita manutenção, para coisas 'simples', mas não há dúvida que o SQL puro é mais performático e mais poderoso.

Só usa ORM ate o calo da performance apertar meu amigo, quando o sistema comeca a perder performance comeca a migrar pra sql puro, pra mim se tem join ja nao vale a pena por no orm

Assunto muito bom pra levantar a discussão. Acredito que tudo tem seu peso, e como você disse a experiencia com o anterior conta. Acredito que quem programou antes dos ORMs tem facilidade para utilizar e entender. Também acredito que quem vai diretamente pro ORM porem não está avançado no conceito de SQL acabará tendo problemas. Acho que tudo que vem pra ajudar é bom para tecnologia, porem sempre devemos entender pro qual motivo aquilo veio pra ajudar, qual dor ele resolveu e como era antes disso. Como alguns amigos da comunidade sempre dizem volte para base, estudo o conceito e todos ganharão. Abraços!

👍👍👍

👏👏👏👏

que tal query builder e mesclar raw sql?

Eu conheco bem sql puro e vivi minha Vida escrevendo eles. Estou aqui tentando decidir se passo a usar um orm em uma nova app que quero fazer. Estou convencido que nao usarei orm.Maaaas.. tem um ponto que é imbativel, e é um desejo antigo meu e esta me pressionando a mudar de ideia e usar sim um orm: com um orm eu posso ter minha apo rodando em N bancos diferentes (sql, oracle, postgree, mysql) , “de graca”, podendo usar os bancos/licencas que o seu cliente ja possua. O que acham ?

Na minha opinião, a principal vantagem do ORM é a possibilidade de mudar o banco sem precisar rever todo código. Para tarefas simples, CRUD por exemplo, ORM vai bem tb, mas em tarefas complexas, como mencionado por você, ORM se torna um grande custo, tanto na implementação quanto no processamento. No final tudo é uma questão de trade off.

Toda vez eu consulto o Google porque esqueço do SQL. rsrs

geralmente o ponto fraco dos ORMs é nos join mesmo, nesses casos eu escrevo SQL puro. Pra CRUD e query numa única tabela os ORMs dão mais agilidade.

Na verdade não faz sentido ter medo de aprender nada né. Isso na real é o grande benefício. Saber cada vez mais mais e isso tudo é oportunidade.

Eu prefiro SQL mil vezes

Acredito que o orm traga uma produtividade inicial maior em alguns casos, mas não tinha parado para pensar que confirme as consultas vão ficando mais complexas a produtividade pode nivelar e aí o desempenho das consultas diretas podem se destacar ainda mais

Acho que uma coisa que não dá pra aceitar em relação a ORM é achar que você sozinho (ou aquele colega de trabalho convencido) vai criar uma lib própria que funciona melhor do que já existe na comunidade 😂

eu uso o Sequelize com o Node, pra mim é melhor...escrevo menos códigos, e fico mais produtivo :)

Se você estuda engenharia de software, é um arquiteto de software é simples a resposta: SQL puro sempre. Agora, se vc é consultor, vai lá fazer o sistema e não está muito preocupado na manutenção ou em como o sistema evoluirá no futuro, é comum usarem ORM. Sabe o vendor lock-in ? o ORM seria um... technology lock-in, algo parecido, é interessante para o fabricante do ORM que você fique ligado a eles, estude eles, e pare de usar SQL puro. Em 3 projetos que participei usando ORM deram problema, num deles caiu até diretor e tiveram que voltar ao SQL. Então hoje se a vaga pede ORM recuso sem cerimônia. Tô fora.