SQL ou ORM: E Agora? (Não tenha medo de SQL)

Nesse vídeo vamos discutir um pouco sobre a utilização de ORM, ou Object Relational Mapper, e a respeito de quando vale a pena utilizar somente SQL.

Acompanhe nossas redes sociais:

Conheça todos os nossos treinamentos:

Quer me conhecer melhor:

Outras informações:

🇧🇷Idioma: PT/BR

[JLDRPT]

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.

[DiegoMedinaP]

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.

[TheBielzinho]

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.

[principe.borodin]

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

[pensandoemsoftware]

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.

[carlosthompson]

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

[fabiomonteiro]

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

[RafaelAmorimmeu]

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

[williammenezes]

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.

[alanctnk]

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

[hhjyidd]

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

[giulianonaspolini]

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.

[mauroanselmooliveira]

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.

[viniciuspereira]

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

[ofabiobraga]

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.

[JoseRicardo-rdey]

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

[znh_]

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.

[vagner.cardoso]

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

[rotognin]

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á

[rgelonezi]

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.