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.
Achei interessante esse comentário sobre saber SQL estará salvo com qualquer linguagem. Particularmente estudo Oracle e trabalho com ele a um bom tempo e agora estou nos estudos principalmente em node js. É uma mudança bem considerável, mas, estamos na luta. Vejo muito gente trabalhando com frameworks, mas a base de sql não é tão evoluída, e sempre me pergunto sobre a performance disso.
Certamente pra quem quer fazer uma query personalizada e que precisa retornar x colunas que vem de 2/3 tabelas, é muito melhor fazer na mão do que depender de ORM. Você sabe o que vai retornar pq você sabe a query que você criou. Eu particularmente gosto muito mais de criar minhas consultas do que depender de um ORM pra fazer as coisas pra mim.
Grande Joao Ribeiro... aprendi muuito com esse portuga. Essa sabe o que fala pessoal, olhem o canal dele! É um professor foda! Abracos Joao.
3 ปีที่แล้ว +1
Concordo e tenho outro ponto a acrescentar: Muitas das vezes os desenvolvedores, pelas facilidades do ORM, não se preocupam em preparar objetos otimizados e geram um enorme gargalo na maioria das aplicações. O simples fato da pessoa ter um bom conhecimento em SQL lhe induz a pensar como tratar o objeto ORM da forma correta, ou seja, abstraindo que atrás do objeto existe uma consulta que é gerada seguindo alguns padrões, que não necessariamente atendem de forma otimizada o cenário apresentado.
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.
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.
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.
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.
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.....
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.
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.
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
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.
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.
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.
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á
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..)
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.
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.
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 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í.
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
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 😎
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
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
é 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 ..
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.
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
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.
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
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.
. 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)! .
Grande Kaichiro! Obrigado por participar! Realmente, analisar performance não é fácil, me lembro de habilitar o modo onde as consultas eram exibidas e copiá-las para executar diretamente no banco de dados, hehehe, o problema começava ai! Grande Abraço!
. Pois é mestre Branas, o grande ponto que acho é que, com a abstração do ORM, tende-se a perder um pouco a performance, pois tudo tem de ser nivelado por baixo, justamente para atender "todos" os casos e consequentemente, a expertise do profissional. Não digo que todo DEV tem que ser Jedi em SQL, mas minimamente saber construir consultas e principalmente saber analizar. Eu também liguei muito o trace do ORM para capturar e analisar a performance do que foi gerado. Te digo que aprendi muito com isto, sabendo o que está sendo gerado e realmente entendo o que faz e o que não faz sentido utilizar dos "benefícios" desta abstração. Acho sim que ORM é importante, mas não é a solução para tudo sempre. Enfim, cada caso, é um caso! Mas saber um pouquinho do quê e como as coisas acontecem nós "bastidores" ajuda e nos torna um profissional melhor....Ah e também compartilhando o que aprendemos ahahahah. Abraço mestre! Lança mais "polêmicas" no twitter, gosto muito de ver as diferentes experiências de todos. "Microsserviço X monolito (distribuido)" quero ver sangue kkkkk. .
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!!
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.
Ó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.
3 ปีที่แล้ว +4
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
Grande Fabrízio, mestre no PostgreSQL! Realmente, ficou sensacional! Te contar um segredo, eu "usava" esse recurso no Sybase, como uma coluna "long varchar", hahaha, mas usando JSON só no nível da aplicação... Quando vi que o PostgreSQL tinha nativamente, nossa, agregou muito! Hoje temos alguns tipos de dados que sempre são JSON, geralmente aquele que tem estrutura variável mesmo (formulários dinâmicos, regras de disparo de email, configuração de gateway de pagamento), temos casos onde criamos até mesmo agregações em colunas JSON. Quando eu falo JSON, na verdade me refiro a JSONB mesmo, falo mais JSON só pra todos entenderem... Obrigado por participar, qualquer hora temos que trocar uma ideia sobre PostgreSQL numa live eim! Abraços!
3 ปีที่แล้ว +2
@@RodrigoBranas Esse "truque" de usar um VARCHAR para armazenar dados semi-estruturados remete aos antigos XML... hehehehe... BTW no PostgreSQL também temos um datatype XML... alias no PostgreSQL desde sempre é possível criar o seu próprio tipo de dados, então vc pode criar coisas com CPF, CNPJ, etc direto dentro do banco de dados com as devidas regras de validação como qualquer outro tipo de dados... e se for mais a fundo tb criar as devidas "OPERATOR CLASS" para vc construir indices com a devida regra de comparação para seu tipo de dados customizado... pouca gente usa isso porque como vc falou no video acaba ficando restrito ao framework e perde oportunidade de usar recursos bacanas do banco de dados.
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....
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 👍
Desde 2018 venho usando o Jooq para fazer os mapeamentos SQL. Hoje já não penso em volta a usar hibernate. Hibernate e JPA funciona muito bem quando o app é focado em CRUD.
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.
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
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 🙏👏
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.
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.
Numa vaga agora estou olhando como se dá o acesso a dados. Escolho a que não usa ORM, gosto de ter o controle mais na mão. acho mais tranquilo para manter e estender o sistema. Já recusei algumas vagas por causa disso. Essa tecnologia considero vergonhosa se tiver que mudar de área por isso mudarei sem remorso.
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.
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
Para gerar relatórios complexos eu demorava demais pra descobrir como fazer em JPA. Desisti e só faço em SQL. Mas para outras cotas continuo usando o ORM.
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.
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!
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.
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.
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…
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.
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.
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!
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ó
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!
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.
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.
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
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.
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.
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
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.
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!
Iria Além. Seria uma proposta ORM first. Usaria o SQL dentro do ORM pra consultas performáticas. Por exemplo, eu poderia criar visões com os relatórios e "proxiar" numa entidade do ORM, ou até trabalhar em cima de Materialized views... ou se a pessoa tiver um DBA, chamar stored procedures dentro do próprio ORM, simplificando as chamadas. Excelente conteúdo. ;)
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!
Ué não entendi, na minha opinião o ponto forte dos ORMs são a facilidade de fazer relacionamentos, qual/quais ORMs você usou pra achar isso? Com o eloquent do laravel e um pouco de programação funcional simplifica qualquer relacionamento entre tabelas
ó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?
Grande Cleyton, beleza? Obrigado por acompanhar, claro, acho que o meio termo sempre é o melhor caminho agregando ferramentas que podem ajudar a fazer inserts, updates, deletes e as vezes deixando SQLs mais complexos pra recursos mais nativos
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 ?
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.
SQL ou ORM? Como quase tudo na programação, depende. Sempre estamos ligados a um contexto, que para ser resolvido deve ser analisado para dai sim ter uma resposta "definitiva". A bala de prata na programação simplesmente não existe, precisamos nos manter atualizados e com o leque de opções em dia para atacar cada contexto deixando a implementação da solução o mais simples possível.
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.
Achei interessante esse comentário sobre saber SQL estará salvo com qualquer linguagem.
Particularmente estudo Oracle e trabalho com ele a um bom tempo e agora estou nos estudos principalmente em node js.
É uma mudança bem considerável, mas, estamos na luta.
Vejo muito gente trabalhando com frameworks, mas a base de sql não é tão evoluída, e sempre me pergunto sobre a performance disso.
Certamente pra quem quer fazer uma query personalizada e que precisa retornar x colunas que vem de 2/3 tabelas, é muito melhor fazer na mão do que depender de ORM. Você sabe o que vai retornar pq você sabe a query que você criou. Eu particularmente gosto muito mais de criar minhas consultas do que depender de um ORM pra fazer as coisas pra mim.
Grande Joao Ribeiro... aprendi muuito com esse portuga. Essa sabe o que fala pessoal, olhem o canal dele! É um professor foda! Abracos Joao.
Concordo e tenho outro ponto a acrescentar: Muitas das vezes os desenvolvedores, pelas facilidades do ORM, não se preocupam em preparar objetos otimizados e geram um enorme gargalo na maioria das aplicações. O simples fato da pessoa ter um bom conhecimento em SQL lhe induz a pensar como tratar o objeto ORM da forma correta, ou seja, abstraindo que atrás do objeto existe uma consulta que é gerada seguindo alguns padrões, que não necessariamente atendem de forma otimizada o cenário apresentado.
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.
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.
Também dou de Delphi e foi a melhor escolha de SQL que tive kkkkkkkkkkkk
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.
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.
Sql manual ou ORM nada funciona se a pessoa não souber o que esta fazendo.
Boa discussão! Eu particulamente sou adepto do modelo ORM com suporte a raw queries para consultas mais complexas.
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.
bem lembrado!
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.....
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.
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.
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
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.
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.
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.
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á
Excelente! Faz anos que também abandonei ORMs. No máximo uso um query builder, para facilitar uma paginação no Oracle, por exemplo.
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.
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..)
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.
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.
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 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í.
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
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 😎
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
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/
Desse cara tá em outro nível. Nível internacional.
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
é 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 ..
Grande Branas, achei muito pertinentes suas ponderações. Show de bola!
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.
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
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.
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
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.
. 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)! .
Grande Kaichiro! Obrigado por participar! Realmente, analisar performance não é fácil, me lembro de habilitar o modo onde as consultas eram exibidas e copiá-las para executar diretamente no banco de dados, hehehe, o problema começava ai! Grande Abraço!
. Pois é mestre Branas, o grande ponto que acho é que, com a abstração do ORM, tende-se a perder um pouco a performance, pois tudo tem de ser nivelado por baixo, justamente para atender "todos" os casos e consequentemente, a expertise do profissional. Não digo que todo DEV tem que ser Jedi em SQL, mas minimamente saber construir consultas e principalmente saber analizar. Eu também liguei muito o trace do ORM para capturar e analisar a performance do que foi gerado. Te digo que aprendi muito com isto, sabendo o que está sendo gerado e realmente entendo o que faz e o que não faz sentido utilizar dos "benefícios" desta abstração. Acho sim que ORM é importante, mas não é a solução para tudo sempre. Enfim, cada caso, é um caso! Mas saber um pouquinho do quê e como as coisas acontecem nós "bastidores" ajuda e nos torna um profissional melhor....Ah e também compartilhando o que aprendemos ahahahah. Abraço mestre!
Lança mais "polêmicas" no twitter, gosto muito de ver as diferentes experiências de todos.
"Microsserviço X monolito (distribuido)" quero ver sangue kkkkk. .
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!!
Fantástico!!! Excelente provocação!!!
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.
Ó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.
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
Grande Fabrízio, mestre no PostgreSQL! Realmente, ficou sensacional! Te contar um segredo, eu "usava" esse recurso no Sybase, como uma coluna "long varchar", hahaha, mas usando JSON só no nível da aplicação... Quando vi que o PostgreSQL tinha nativamente, nossa, agregou muito! Hoje temos alguns tipos de dados que sempre são JSON, geralmente aquele que tem estrutura variável mesmo (formulários dinâmicos, regras de disparo de email, configuração de gateway de pagamento), temos casos onde criamos até mesmo agregações em colunas JSON. Quando eu falo JSON, na verdade me refiro a JSONB mesmo, falo mais JSON só pra todos entenderem... Obrigado por participar, qualquer hora temos que trocar uma ideia sobre PostgreSQL numa live eim! Abraços!
@@RodrigoBranas Esse "truque" de usar um VARCHAR para armazenar dados semi-estruturados remete aos antigos XML... hehehehe... BTW no PostgreSQL também temos um datatype XML... alias no PostgreSQL desde sempre é possível criar o seu próprio tipo de dados, então vc pode criar coisas com CPF, CNPJ, etc direto dentro do banco de dados com as devidas regras de validação como qualquer outro tipo de dados... e se for mais a fundo tb criar as devidas "OPERATOR CLASS" para vc construir indices com a devida regra de comparação para seu tipo de dados customizado... pouca gente usa isso porque como vc falou no video acaba ficando restrito ao framework e perde oportunidade de usar recursos bacanas do banco de dados.
Top Branas!!! Passei por essas situações também!
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....
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 👍
Já tá usando em produção? Como tem sido a experiência?
O prisma não deixa de ser quase uma orm.
Desde 2018 venho usando o Jooq para fazer os mapeamentos SQL. Hoje já não penso em volta a usar hibernate. Hibernate e JPA funciona muito bem quando o app é focado em CRUD.
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.
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
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 🙏👏
Concerteza Branas. Eu compartilho da mesma ideia. Quando falamos de sistema, e o que vamos utilizar, e falo sempre depende
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.
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.
Numa vaga agora estou olhando como se dá o acesso a dados. Escolho a que não usa ORM, gosto de ter o controle mais na mão.
acho mais tranquilo para manter e estender o sistema. Já recusei algumas vagas por causa disso. Essa tecnologia considero vergonhosa se tiver
que mudar de área por isso mudarei sem remorso.
Concordo totalmente
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.
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
Para gerar relatórios complexos eu demorava demais pra descobrir como fazer em JPA. Desisti e só faço em SQL. Mas para outras cotas continuo usando o ORM.
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.
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!
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.
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.
Belo ponto de vista para refletir. Nunca tinha pensado desta forma. Excelente vídeo!
Obrigado Ricardo!
problema é fazer os desenvolvedores parar de usar orm sempre estão pensando em crud mesmo quando não é preciso
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…
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.
Jooq é ótimo, pena que só é free pra bancos open source
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.
Volta, pfvr a gravar e a dar aula.😢😢😢
Parabéns pelo video Branas, show de bola.
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!
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ó
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!
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.
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.
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
Muito bom mesmo! Parabéns, Rodrigo.
👍👍👍
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.
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.
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
@@c.r.y.o.g.e.n kkkkkk, imagino pq são SQLs genéricos
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.
eu uso o Sequelize com o Node, pra mim é melhor...escrevo menos códigos, e fico mais produtivo :)
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!
Ao meu ver o principal ponto que você tocou foi o seguinte: "Combinar ORM E SQL puro", tudo vai da necessidade!
Iria Além. Seria uma proposta ORM first. Usaria o SQL dentro do ORM pra consultas performáticas. Por exemplo, eu poderia criar visões com os relatórios e "proxiar" numa entidade do ORM, ou até trabalhar em cima de Materialized views... ou se a pessoa tiver um DBA, chamar stored procedures dentro do próprio ORM, simplificando as chamadas. Excelente conteúdo. ;)
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
Hoje em dia prefiro usar query builder como o knex, ORM no fim das contas é dor de cabeça
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!
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.
Ué não entendi, na minha opinião o ponto forte dos ORMs são a facilidade de fazer relacionamentos, qual/quais ORMs você usou pra achar isso? Com o eloquent do laravel e um pouco de programação funcional simplifica qualquer relacionamento entre tabelas
@@FernandoSilvaSousa eu uso Django do python. Lá por exemplo não consigo fazer self join, update join, etc
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
ó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?
Show demais Branas 👏 👏 E um Query builderzinho ? Tá ali no meio termo rsrs
Grande Cleyton, beleza? Obrigado por acompanhar, claro, acho que o meio termo sempre é o melhor caminho agregando ferramentas que podem ajudar a fazer inserts, updates, deletes e as vezes deixando SQLs mais complexos pra recursos mais nativos
Toda vez eu consulto o Google porque esqueço do SQL. rsrs
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 ?
que tal query builder e mesclar raw sql?
Sou SQL raiz! =)
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 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.
SQL ou ORM? Como quase tudo na programação, depende. Sempre estamos ligados a um contexto, que para ser resolvido deve ser analisado para dai sim ter uma resposta "definitiva". A bala de prata na programação simplesmente não existe, precisamos nos manter atualizados e com o leque de opções em dia para atacar cada contexto deixando a implementação da solução o mais simples possível.