ORM: концепция, плюсы и минусы относительно чистого SQL

Введение

Весь предыдущий цикл разбирал SQL напрямую — ORM (Object-Relational Mapping) предлагает альтернативный подход: работу с данными через объекты языка программирования, автоматически транслируемую в SQL-запросы соответствующей библиотекой, без необходимости писать SQL вручную для большинства типичных операций. В статье разберём концепцию ORM и взвешенно сравним её с прямым использованием SQL, опираясь на всё разобранное ранее в цикле.

Концепция

ORM отображает таблицы БД на классы языка программирования, а строки таблиц — на экземпляры этих классов, давая разработчику возможность оперировать привычными объектами и их методами, а не текстовыми SQL-запросами — типичные операции (получить объект по ID, сохранить изменённый объект, найти объекты по условию) выражаются через API языка программирования, который ORM транслирует во соответствующий SQL под капотом. Это даёт реальные практические выгоды (меньше повторяющегося, «шаблонного» кода для простых CRUD-операций — Create/Read/Update/Delete; некоторую защиту от SQL-инъекций «по умолчанию», статья 433, поскольку большинство ORM используют параметризацию автоматически), но за счёт снижения прямого контроля над точным, итоговым SQL-запросом и риска неэффективных запросов, не очевидных из кода на уровне объектов (классическая N+1 проблема, статья 421, особенно характерна именно для ORM-кода).

Пример кода: ORM

// Концептуальный пример ORM-подобного кода (псевдокод, иллюстрирующий общий подход;
// для Qt-специфичной реальности см. статью 437 про QSqlTableModel)
class Customer {
public:
    int id;
    QString name;
    QString email;

    static Customer findById(int id); // ORM скрывает: SELECT * FROM customers WHERE id = ?
    void save();                       // ORM скрывает: INSERT или UPDATE, в зависимости от состояния объекта
    static QList<Customer> findWhere(const QString &condition); // ORM строит SELECT с условием
};

void exampleOrmUsage()
{
    Customer customer = Customer::findById(5);
    customer.email = "new_email@example.com";
    customer.save(); // под капотом — эквивалент UPDATE customers SET email = ? WHERE id = ?
}

-- Эквивалентный, явный SQL-код для того же действия —
-- то, что реально выполняется "под капотом" ORM в примере выше
SELECT * FROM customers WHERE id = 5;
UPDATE customers SET email = 'new_email@example.com' WHERE id = 5;

// Скрытая опасность ORM — незаметная N+1 проблема (статья 421) через "удобный" API
void demonstrateHiddenN1Problem()
{
    QList<Order> orders = Order::findAll(); // один запрос — все заказы

    for (const Order &order : orders) {
        Customer customer = order.getCustomer(); // КАЖДЫЙ вызов — отдельный, скрытый SQL-запрос!
        qDebug() << customer.name;
    }
    // Итог: 1 + N запросов, хотя из кода это выглядит как простой, "невинный" цикл
    // без какого-либо явного указания на множественные обращения к БД
}

Пояснения к коду

Сравнение ORM-подобного кода Customer::findById(5)/customer.save() с эквивалентным явным SQL показывает основную выгоду ORM — значительно более компактный, выразительный код для типичных, повторяющихся операций, не требующий явного написания SQL для каждой такой операции вручную. Демонстрация скрытой N+1 проблемы — ключевой, практически важный подводный камень самой парадигмы ORM: вызов order.getCustomer() внутри цикла выглядит как простое, «бесплатное» обращение к уже загрученному объекту, но на практике незаметно для невнимательного взгляда порождает отдельный SQL-запрос для каждой итерации цикла, что без явного знания внутреннего устройства конкретного ORM и привычки проверять реально генерируемые SQL-запросы (через логирование ORM или инструменты профилирования) легко пропустить при написании кода.

Подводные камни

Полный переход на ORM с отказом от понимания и проверки реально генерируемого SQL, в надежде, что ORM «сам разберётся» с производительностью — как явно показывает пример с N+1, ORM абстрагирует написание SQL, но не освобождает разработчика от необходимости понимать, какой именно SQL реально выполняется под капотом, особенно для не самых простых, нетривиальных операций; большинство серьёзных ORM предоставляют механизмы логирования или явной «разъяснённой» загрузки данных (eager loading, явно загружающий связанные данные одним эффективным запросом вместо отдельных запросов для каждого объекта), и умение пользоваться ими — необходимая часть эффективного использования ORM, а не опциональная деталь.
Использование ORM для действительно сложных, специализированных запросов (многоуровневая агрегация, оконные функции из статьи 404, рекурсивные CTE из статьи 405), для выражения которых через ограниченный, объектно-ориентированный API ORM либо невозможно, либо крайне неудобно по сравнению с прямым, явным SQL — большинство зрелых ORM предоставляют «escape hatch» (возможность выполнить произвольный, «сырой» SQL-запрос напрямую, минуя обычный объектный API) именно для таких случаев, и знание, когда стоит воспользоваться этой возможностью вместо настойчивых попыток выразить сложную логику через ограниченные конструкции объектного API, важно для практичного, сбалансированного использования ORM.
Полное отвержение ORM «принципиально» в пользу исключительно прямого SQL для всех без исключения случаев, даже для большинства простых, типичных CRUD-операций, где ORM реально даёт значительную экономию времени и уменьшение повторяющегося кода без существенных компромиссов — крайности в любую сторону (полный отказ от ORM или полная, безоговорочная зависимость от него) редко оптимальны; практичный, сбалансированный подход обычно использует ORM для большинства типичных, простых операций, и явный, прямой SQL для специфичных, сложных или критичных по производительности случаев.
Игнорирование того, что ORM добавляет дополнительный слой абстракции с собственными накладными расходами, который не бесплатен даже для относительно простых операций — для критичных по производительности участков кода (горячие пути выполнения с очень частыми обращениями к БД) накладные расходы самого ORM (построение объектов, дополнительная логика отслеживания изменений) могут стать заметной частью общей стоимости операции, и для таких конкретных, измеренных случаев прямой, оптимизированный SQL-запрос (или хотя бы «сырой» SQL-режим того же ORM) может оказаться предпочтительнее обычного, объектного API ORM.