Qual usar – ORM ou SQL?

Sem dúvida o modelo ORM – Object Relational Mapping – facilita a vida de muitos desenvolvedores. Seu objetivo é ser a ponte entre o mundo da POO e o mundo dos modelos relacionais.

Mas será que ele é sempre a melhor escolha? Qual usar, ORM ou SQL? Vamos verificar junto com exemplos em Python e SQL!

ORM

A interface que o ORM fornece ao desenvolvedor está atrelada a chamada de métodos e passagem de parâmetros. Como este código abaixo em python:

stmt = select(User).where(User.name.in_(["juliana", 'sandy'])

Não precisar se preocupar com a query a ser realizada, de fato é uma grande vantagem dessa abordagem.

Em contra partida realizar um select seria assim:

SELECT * FROM User 
                  WHERE name = "juliana" 
                                 OR name = "sandy"

Eu poderia ter usado o like no lugar do sinal de igual, mas ele geralmente é acompanhado de caracteres especiais ( %, _ ) para determinar um match.

OK… neste exemplo pode até não ser tão mais fácil. Imagine então criar uma junção:

stmt_join = select(User.fullname, Address.email_address).join_from(Address, User)

Sua versão em SQL:

SELECT u.fullname, u.email_address 
              FROM User AS u 
              JOIN Address AS a

Como trata-se de um natural join a claúsula de junção foi omitida, caso contrário poderiamos inserir: ON u.id == a.id_user

O modelo ORM – Object Relational Mapping – fornece transparência, na construção da query SQL, e consequentemente no acesso ao banco de dados. Realmente para diversos cenários é a melhor abordagem, ou a mais simples

SQL CORE

Mas se fossem apenas flores, por que então temos a versão CORE (como no SQLalchemy com python)?

sql_insert = text("insert into user values(2,'Maria','email@email.com','Ma')")
engine.execute(sql_insert)

Para queries simples (a maioria dos casos) o ORM facilita nosso trabalho. Contudo, você já se deparou com aquelas queries gigantes? Bem características da área de análise de dados, por exemplo?

Imagine o cenário hipotético de verificar a lista de contato dos alunos matriculados na pós e alunos avulsos matriculados em classes do programa de pós-graduação

with alunos as (
      -- alunos_avulsos
      SELECT id FROM user AS u
          INNER JOIN  user_has_class AS uhc 
              ON u.id == uhc.id_user
              AND uhc.date == date_trunc(year, current_date())
           WHERE u.active is true
UNION
      -- alunos_matriculados na pos
      SELECT id FROM user AS u
           INNER JOIN  user_has_program AS uhp 
                ON u.id == uhc.id_user
                AND uhc.date == date_trunc(year, current_date())
           WHERE u.active is true
);

SELECT u.name AS 'Nome', 
       u.email, 
       u.phone as 'Contato' 
FROM User AS U WHERE u.id IN (alunos)
ORDER BY 1;

O que fazer? ORM ou SQL?

Neste cenário se torna bem mais complicado o mapeamento a ser feito. Muitas vezes você irá revirar a documentação do ORM para encontrar a maneira de estruturar aquela query.

Este acima foi apenas um exemplo, a queires bem mais complexas do que esta.

Então… o tempo que você pode levar para adequar ao ORM, pode não valer a pena! Esse é um dos motivos pelo qual o bom e velho SQL é utilizado em detrimento do ORM.

As vezes dedicar um tempo para aprender uma nova skill, como SQL, pode tornar sua vida mais simplificada!

Para mais informações sobre o mundo da tecnologia siga

– Juliana Mascarenhas
– Dalbert Mascarenhas
– Simplificando Redes/Programação
– Canal no Youtube: https://lnkd.in/dm_4uMyp
– Site/blog SR: www.simplificandoredes.com

Quem entender melhor o que são banco de dados? Acesse o link para o artigo SR: Entenda o que são banco de dados