Um ORM ruim é infinitamente pior do que uma SQL ruim

Isso é um discurso um pouco retórico, e eu me desculpo por isso. Parece que ultimamente tenho cada vez mais me confrontado com implementações ORM que podem parecer bem superficialmente, mas que são assassinas para seu aplicativo. No final, é sempre um caso de uso ORM ruim, falta de conhecimento do desenvolvedor… mas acredito que isso apenas reforça o meu ponto: é muito fácil escrever um ORM ruim, seja Doctrine, Propel…

Ei, isso parece que pode funcionar

Em um mundo ORM, é muito fácil escrever algo como isto (eu digo que é fácil, não correto).

<?php
    // First, get all the companies in your database
    $companies = $this->getAllCompanies();
    $totalValue = 0;
    foreach ($companies as $company) {
        // For each company there is, retrieve the total value of all their orders
        $orders = $company->getOrders();
        foreach ($orders as $order) {
            $totalValue += (float) $order->getValue();
        }
 
        echo "This company made us ". $totalValue ." euro already.";
    }
 ?>

Se você já usou PHP por mais de 3 meses, o exemplo acima lhe dará arrepios na espinha. Ele se parece com um código perfeitamente válido, até faz sentido lê-lo. Mas, na realidade, provavelmente ele faz algo parecido com isto:

<?php
    // First, get all the companies in your database
    SELECT * FROM "company";
    $totalValue = 0;
    foreach (...) {
        // For each company there is, retrieve the total value of all their orders
        SELECT * FROM "order" WHERE companyid = $companyid;
        foreach (...) {
            $totalValue += $row->value;
        }
 
        echo "This company made us ". $totalValue ." euro already.";
    }
 ?>

O fragmento de código acima irá piorar progressivamente à medida que seu aplicativo crescer. Por quê? Porque enquanto você tiver mais entradas na tabela “company”, o seu primeiro foreach-loop vai crescer, desde que você repita cada entrada na tabela. Como resultado disso, ainda mais consultas na tabela “order” estarão sendo executadas. Então, toda vez que sua base de clientes crescer (mais entradas na tabela “company”), o código acima ficará mais lento e você irá prejudicar o seu banco de dados com mais e mais consultas (simples), conforme você iterar cada tabela para cada linha.

ORM ruim é muito fácil escrever

Meu problema com ORM é que é muito fácil escrever código ruim. É muito fácil usar todos os mapeamentos padrão e apenas fazer “SELECT *” no background. Cada sistema ORM oferece a você a capacidade de escrever consultas SQL personalizadas, mas isso desafia o ponto do ORM em geral, portanto, dificilmente alguém o faz. Como mais e mais desenvolvedores usam ORM apenas para criar aplicativos, eles perdem o seu contato com a interação do banco de dados, as consultas por trás dele, o raciocínio do porquê usar certo tipo de consulta, o impacto no desempenho de joins INNER ou OUTTER…

O exemplo acima, causando várias pequenas consultas, também poderia ser substituído por uma consulta eficiente para lhe dar o mesmo resultado.

SELECT SUM(o.VALUE) AS TotalValue, c.name AS CompanyName
FROM company AS c
LEFT JOIN "order" AS o ON o.companyid = c.companyid
GROUP BY o.companyid;

E não é uma consulta difícil.

A falta de visibilidade

Se você der uma olhada nos dois exemplos acima de código, acho que é um pouco óbvio que o exemplo 2 – no qual as consultas SQL são exibidas – mostra muito rapidamente que se trata de um código ruim. Ele mostra as consultas SQL que serão executadas e, se você pensar logicamente por 1.5s, estará ciente de que é uma coisa ruim para escrever, embora o exemplo ORM pareça perfeitamente válido e o gargalo de desempenho pode não ser imediatamente claro.

E isso simplesmente pode ser a minha maior frustração com ORM: como desenvolvedor, você perder o foco sobre as consultas SQL subjacentes. Alguns podem alegar que isso não é importante, que é exatamente a razão pela qual ORM está ganhando tanta atenção. Mas se você for sério sobre como ajustar seu aplicativo, você precisa de conhecimento do SQL que está sendo executado. Você precisa saber como escrever consultas eficientes com JOIN’S complexas, GROUP BY’s e funções agregadas, como SUM (), AVG (), …

Oh você, dominou ORM!

Sim. Você não escreve um código estúpido se você domina suas ferramentas, e isso inclui frameworks ORM também. Eu tenho certeza de que existem pessoas que escrevem códigos ORM perfeitos para alto desempenho, parece que tenho apenas que encontrá-las.

Se você discordar de mim, me prove que estou errado.

?

Texto original disponível em http://mattiasgeniar.be/2012/03/30/bad-orm-is-infinitely-worse-than-bad-sql/