Что такое ORM: плюсы, минусы и популярные решения

Что такое ORM

ORM (Object-Relational Mapping) — это слой между кодом приложения и реляционной базой данных. Вы описываете модели — User, Order, Product — а ORM сопоставляет их с таблицами, превращает вызовы методов в SQL и возвращает результат в виде объектов.

Вместо строки SELECT * FROM users WHERE is_active = true вы пишете что-то вроде User.objects.filter(is_active=True), а ORM сама соберёт запрос, подставит параметры и создаст объекты.

Популярные ORM

Так выглядит один и тот же запрос «активные пользователи с заказами» в Prisma:

const users = await prisma.user.findMany({
  where: { isActive: true },
  include: { orders: true },
});

Плюсы

• Скорость разработки. Типовые операции создания, чтения и обновления пишутся в одну строку.
• Безопасность. Параметры подставляются автоматически, что защищает от SQL-инъекций при обычном использовании.
• Миграции. Изменения схемы фиксируются в коде и применяются одинаково на всех окружениях.
• Типизация и автодополнение. Особенно у Prisma и современных версий SQLAlchemy: ошибки в названиях полей видны до запуска.
• Переносимость. Сменить PostgreSQL на MySQL проще, хотя на практике это редко бывает бесплатно.

Минусы

• Скрытые запросы. Одна строка кода может породить десятки SQL-запросов.
• Неоптимальный SQL для сложных отчётов, оконных функций и специфичных возможностей базы.
• Ещё одна абстракция. Чтобы отлаживать производительность, всё равно нужно понимать SQL и индексы.

Проблема N+1

Самая известная ловушка ORM. Вы получаете список из N записей одним запросом, а затем в цикле обращаетесь к связанному объекту — и ORM для каждой записи делает ещё один запрос. Итого N+1 запрос вместо одного-двух.

# Django: 1 запрос за заказами + по запросу на каждого клиента
for order in Order.objects.all():
    print(order.customer.name)

# Исправлено: заказы и клиенты загружаются одним запросом с JOIN
for order in Order.objects.select_related("customer"):
    print(order.customer.name)

На локальной базе с десятью заказами разницы не видно. В продакшене с тысячами строк и сетевой задержкой страница начинает грузиться секундами.

Как это решают в разных ORM:

• Django — select_related для связей «один к одному» и «многие к одному», prefetch_related для «один ко многим».
• SQLAlchemy — опции загрузки selectinload и joinedload.
• Prisma — include или select со связанными моделями.
• Hibernate — JOIN FETCH в JPQL-запросе или entity graphs.

Главное — включить логирование SQL в разработке и смотреть, сколько запросов делает каждая страница.

Когда лучше обычный SQL

• Отчёты и аналитика: сложные агрегации, оконные функции, CTE.
• Массовые операции: обновить или вставить сотни тысяч строк за раз.
• Специфичные возможности базы: полнотекстовый поиск, JSONB-операторы, upsert с особыми условиями.
• Критичные по скорости запросы, где нужен полный контроль над планом выполнения.

Почти все ORM позволяют выполнить сырой SQL там, где это нужно. Нормальная практика — ORM для большей части типовой работы и SQL для узких мест.