ORM

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

ORM широко используется в Backend-разработке на Python, Java, C#, PHP, JavaScript и других языках. Она особенно удобна для типовых операций создания, чтения, изменения и удаления данных.

Например, вместо ручного SQL-запроса к таблице users приложение может создать объект User, задать ему имя и email, а ORM самостоятельно сформирует INSERT.

Что такое ORM простыми словами

ORM можно представить как переводчика между объектами приложения и реляционной базой данных.

В программном коде разработчик работает с объектом пользователя:

User
 id = 125
 name = "Иван"
 email = "ivan@example.com"

В базе тот же пользователь хранится как строка таблицы users.

ORM сопоставляет объект User с таблицей users, а свойства объекта — со столбцами.

ORM позволяет разработчику работать с данными через модели языка программирования, но фактически за ними по-прежнему стоят SQL-запросы и реляционная база.

Что означает Object-Relational Mapping

Object означает объектную модель приложения, Relational — реляционную модель базы данных, а Mapping — правила их сопоставления.

Например, класс Order может соответствовать таблице orders, поле Order.status — столбцу status, а связь Order.customer — внешнему ключу customer_id.

Для чего нужна ORM

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

• создание записей;
• получение данных;
• обновление объектов;
• удаление строк;
• описание связей;
• управление транзакциями;
• создание миграций;
• валидация моделей;
• формирование SQL-запросов.

ORM и SQL

ORM не заменяет SQL как технологию работы реляционной СУБД.

Когда разработчик пишет запрос через ORM, Framework преобразует его в SQL, который выполняет PostgreSQL, MySQL, Microsoft SQL Server, Oracle Database или другая СУБД.

Поэтому производительность ORM-приложения напрямую зависит от качества создаваемого SQL.

Пример без ORM

Для получения пользователя разработчик может написать SQL вручную.

SELECT id, name, email
FROM users
WHERE id = 125;

После этого результат нужно преобразовать в объект программы.

Пример с ORM

При использовании ORM код может выглядеть концептуально так:

user = User.find(125)

ORM формирует подходящий SELECT, отправляет его СУБД, получает строку и создает объект User.

Конкретный синтаксис зависит от Framework и языка программирования.

Что такое ORM Model

Model описывает сущность приложения и ее связь с таблицей.

Например, модель пользователя может содержать id, name, email и created_at.

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

Model и таблица

В простом случае одна Model соответствует одной таблице.

Но сложная ORM может использовать наследование, вычисляемые поля и более развитые стратегии Mapping.

ORM и CRUD

CRUD обозначает Create, Read, Update и Delete.

Это основная область, где ORM значительно сокращает количество шаблонного SQL-кода.

Создание записи через ORM

Разработчик создает объект и сохраняет его.

user = User(
 name="Иван",
 email="ivan@example.com"
)
user.save()

ORM преобразует эту операцию в INSERT.

Чтение данных

Для чтения ORM предоставляет Query API.

Например, приложение может запросить всех активных пользователей или одного пользователя по идентификатору.

Под капотом выполняется SELECT с соответствующим WHERE.

Обновление данных

Приложение изменяет свойства объекта и сохраняет изменения.

user.name = "Иван Петров"
user.save()

ORM формирует UPDATE.

Важно понимать, какие именно столбцы обновляются и сколько SQL-запросов выполняется.

Удаление данных

Удаление Model обычно приводит к SQL DELETE или к логическому удалению, если приложение реализует Soft Delete.

Необходимо учитывать связи и Cascade Rules, чтобы случайно не удалить связанные бизнес-данные.

Что такое Query Builder

Query Builder позволяет программно собирать запросы без написания полного SQL вручную.

Он может быть частью ORM или отдельным инструментом.

Query Builder обычно находится ближе к SQL, чем полноценная ORM: разработчик работает с таблицами, условиями и JOIN, но использует методы языка программирования.

ORM и Query Builder

Во многих проектах оба подхода используются вместе.

ORM и Repository Pattern

Repository может предоставлять отдельный слой доступа к данным поверх ORM.

Например, Backend вызывает UserRepository.findActiveUsers, не зная деталей конкретного ORM Query.

Это уменьшает связанность бизнес-логики с механизмом хранения.

ORM и Active Record

Active Record — подход, при котором сама модель содержит методы сохранения, чтения и удаления.

Объект одновременно представляет данные и умеет взаимодействовать с базой.

Например, user.save() сохраняет объект непосредственно через Model.

Data Mapper

Data Mapper отделяет бизнес-объекты от логики сохранения данных.

Специальный слой Mapper или Session отвечает за преобразование объектов в строки базы.

Этот подход часто удобнее в сложной Domain Model, но требует больше архитектурного кода.

Active Record и Data Mapper

ORM и связи между таблицами

Одно из важных преимуществ ORM — декларативное описание Relations.

Например, пользователь имеет много заказов, а каждый заказ принадлежит одному пользователю.

ORM связывает объекты через Foreign Key.

One-to-One

One-to-One означает связь один к одному.

Например, один пользователь имеет один профиль с дополнительными настройками.

ORM позволяет обращаться к связанному объекту через свойство модели.

One-to-Many

One-to-Many — одна из самых распространенных связей.

Один customer может иметь множество orders.

В реляционной базе orders содержит customer_id, а ORM предоставляет коллекцию customer.orders.

Many-to-Many

Many-to-Many связывает множество объектов одной стороны с множеством объектов другой.

Например, пользователь может иметь много ролей, а одна роль принадлежит многим пользователям.

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

Lazy Loading

Lazy Loading означает, что связанные данные загружаются только при первом обращении.

Например, Backend получает User без Orders, а SQL для заказов выполняется только при обращении к user.orders.

Это экономит ресурсы, если связь не нужна, но может привести к проблеме N+1.

Eager Loading

Eager Loading загружает связанные данные заранее.

Например, ORM получает пользователей вместе с заказами через JOIN или несколько оптимизированных запросов.

Это может устранить N+1, но чрезмерный Eager Loading приводит к загрузке большого количества ненужных данных.

Проблема N+1

N+1 — одна из наиболее известных проблем ORM.

Представим, что Backend получает 100 пользователей одним SELECT. Затем код обращается к orders каждого пользователя.

При Lazy Loading ORM может выполнить еще 100 отдельных запросов.

Итого вместо одного или нескольких эффективных запросов база получает 101 операцию.

ORM может сделать неэффективный SQL незаметным в коде, поэтому количество запросов необходимо контролировать через логи и Observability.

Как решить N+1

Обычно применяют Eager Loading, JOIN, Batch Loading или специальные механизмы Preload.

Главная задача — получить связанные данные ограниченным количеством SQL-запросов.

Конкретный механизм зависит от ORM.

ORM и JOIN

ORM позволяет описывать JOIN через Relations или Query API.

Разработчику не обязательно вручную писать ON users.id = orders.user_id.

Но для сложных запросов полезно понимать, какой JOIN фактически сформирован.

ORM и индексы

ORM не создает эффективную Database Schema автоматически во всех ситуациях.

Если приложение часто фильтрует orders по customer_id и created_at, соответствующий индекс все равно необходимо спроектировать.

Без него даже красиво написанный ORM Query может выполнять Full Table Scan.

ORM и Execution Plan

Когда запрос становится медленным, необходимо посмотреть SQL и Execution Plan.

ORM-абстракция не должна мешать работе с инструментами СУБД.

Разработчик проверяет индексы, JOIN, количество обрабатываемых строк и выбирает оптимизацию на основании реальных данных.

ORM и миграции

Многие ORM связаны с системой Database Migrations.

Разработчик изменяет Model или создает Migration, которая добавляет таблицу, столбец или индекс.

Migration хранится в Git и применяется последовательно в development, staging и production.

Почему миграции важны

Без миграций разработчики могут вручную менять Schema в разных окружениях.

Через некоторое время структуры production и development начинают различаться.

Версионируемые миграции делают изменение базы воспроизводимым.

ORM и Schema

ORM-модели часто становятся одним из источников описания структуры приложения.

Но Model и Database Schema не всегда полностью совпадают.

В базе могут существовать Views, Triggers, Stored Procedures, специализированные индексы и ограничения, которые ORM описывает частично или не описывает вообще.

Code First

При Code First разработчик сначала описывает модели в коде, а Framework создает или изменяет Database Schema через миграции.

Такой подход удобен для новых приложений и быстрого развития Domain Model.

Database First

При Database First исходной считается уже существующая Schema.

На основании таблиц генерируются или настраиваются Models.

Этот вариант часто встречается в корпоративных системах с большой исторической базой.

ORM и транзакции

ORM обычно предоставляет API для управления Database Transaction.

Несколько изменений Models можно объединить в одну транзакцию.

Если одно действие завершается ошибкой, ORM выполняет ROLLBACK.

Пример транзакции

При создании заказа приложение должно сохранить order и order_items.

Обе операции должны быть либо подтверждены вместе, либо отменены.

ORM предоставляет Transaction Context, внутри которого выполняются изменения.

ORM и ACID

ACID-гарантии предоставляет СУБД, а ORM помогает приложению использовать транзакции.

ORM не создает Atomicity или Durability самостоятельно.

Если база или Storage Engine не обеспечивает нужные свойства, Framework не сможет их добавить одной настройкой.

Transaction Boundary

Разработчик должен правильно определить границы транзакции.

Слишком маленькая Transaction не защищает связанную операцию, а слишком длинная удерживает ресурсы и увеличивает вероятность конфликтов.

ORM упрощает синтаксис, но архитектурное решение остается за разработчиком.

ORM и Deadlock

ORM не защищает автоматически от Deadlock.

Если две транзакции изменяют ресурсы в разном порядке, база может обнаружить взаимную блокировку.

Backend должен уметь обработать соответствующую ошибку и безопасно повторить операцию, если это допустимо.

ORM и Optimistic Locking

Optimistic Locking помогает обнаружить ситуацию, когда два пользователя изменили одну запись параллельно.

Model может содержать поле version. При UPDATE ORM проверяет, что версия не изменилась с момента чтения.

Если запись уже обновлена другим процессом, возникает конфликт вместо тихого перезаписывания данных.

Pessimistic Locking

Pessimistic Locking предполагает явную блокировку данных перед изменением.

Например, приложение блокирует строку товара перед списанием последнего остатка.

Такой подход может быть необходим для критичных конкурентных операций, но снижает параллельность.

ORM и SQL Injection

Правильно используемая ORM обычно передает значения в SQL как параметры.

Это существенно снижает риск SQL Injection по сравнению с ручной конкатенацией пользовательских строк.

Но ORM не делает приложение автоматически безопасным.

Когда SQL Injection все еще возможен

Разработчик может использовать Raw SQL и самостоятельно вставить пользовательский ввод в строку запроса.

Также опасны динамические имена полей, сортировка и другие элементы, если они формируются без White List.

Даже при ORM входные данные необходимо валидировать.

Raw SQL

Большинство ORM позволяет выполнять SQL вручную.

Это полезно для сложных отчетов, оптимизированных запросов и функций конкретной СУБД.

Использование Raw SQL не является ошибкой само по себе.

Важно применять Parameterized Queries и не терять контроль над безопасностью.

Когда ORM лучше Raw SQL

ORM особенно эффективна для CRUD, стандартных Relations и обычной бизнес-логики.

Код получается короче, единообразнее и проще сопровождать.

Framework также автоматически преобразует результаты базы в объекты.

Когда Raw SQL может быть лучше

Сложная аналитика, большое количество JOIN, оконные функции или критичный по производительности запрос иногда проще и прозрачнее выражаются через SQL.

Не следует превращать ORM Query в десятки вложенных методов только ради принципиального отказа от SQL.

ORM и PostgreSQL

ORM часто используется с PostgreSQL.

Models отображаются на таблицы, Relations — на Foreign Key, а запросы Framework преобразуются в PostgreSQL SQL.

При использовании специфических возможностей PostgreSQL иногда требуется Raw SQL или расширения конкретной ORM.

ORM и MySQL

MySQL также широко используется с ORM.

Framework берет на себя обычные SELECT, INSERT и UPDATE и помогает управлять миграциями.

При этом необходимо учитывать типы данных, индексы и особенности MySQL Dialect.

ORM и MariaDB

Многие ORM могут работать с MariaDB через MySQL-совместимые или специализированные драйверы.

Но при миграции между MySQL и MariaDB необходимо учитывать различия конкретных функций и версий.

ORM и Microsoft SQL Server

В .NET-разработке ORM часто связывает C# Models с таблицами Microsoft SQL Server.

Framework формирует T-SQL, управляет Relations и Database Migrations.

Для оптимизации необходимо анализировать фактический SQL Server Execution Plan.

ORM и Oracle Database

Корпоративные Java и .NET приложения могут использовать ORM с Oracle Database.

Базовые CRUD-операции абстрагируются, но сложная PL/SQL логика и специфические возможности Oracle нередко требуют отдельной интеграции.

ORM и NoSQL

Термин ORM относится именно к Object-Relational Mapping, то есть к реляционным системам.

Для MongoDB и других документных баз корректнее говорить об Object-Document Mapping, или ODM.

Однако в разговорной практике библиотеку работы с NoSQL иногда тоже называют ORM.

ORM и MongoDB

MongoDB не использует классические реляционные таблицы, поэтому связь объектов и документов реализуется через ODM-подходы.

Инструмент может предоставлять Models, Validation и Query API, похожие на ORM.

Но принципы проектирования Documents, Embedding и References отличаются от SQL.

ORM и Backend

ORM обычно находится внутри Backend Data Access Layer.

Frontend отправляет API Request, Backend выполняет бизнес-логику, ORM обращается к СУБД и возвращает объект.

Пользователь не взаимодействует с ORM напрямую.

ORM и REST API

REST API часто использует ORM для получения данных ресурсов.

Например, GET /users/125 приводит к ORM Query по Model User.

Важно не возвращать Model клиенту автоматически целиком, поскольку она может содержать внутренние или чувствительные поля.

ORM и GraphQL

GraphQL особенно чувствителен к неэффективному использованию ORM.

Каждый Resolver может отдельно обращаться к Relation и создавать N+1.

Поэтому применяются Batch Loading, DataLoader-подобные подходы и заранее спроектированные Queries.

ORM и микросервисы

Каждый Microservice может иметь собственную ORM и Database Schema.

Например, order-service использует PostgreSQL через ORM, а catalog-service работает с MongoDB через ODM.

Важно, чтобы один сервис не обращался напрямую к ORM-моделям базы другого сервиса.

ORM и Domain-driven Design

В Domain-driven Design модель предметной области не всегда удобно напрямую связывать с таблицами.

Если Domain Model сложная, Data Mapper помогает отделить бизнес-сущности от Persistence.

Так Database Schema может развиваться независимо от части бизнес-логики.

ORM и Unit of Work

Unit of Work отслеживает изменения объектов в рамках одной логической операции.

Вместо немедленного SQL после каждого изменения Framework собирает изменения и синхронизирует их с базой в подходящий момент.

Этот подход тесно связан с транзакциями.

Identity Map

Identity Map гарантирует, что одна строка базы внутри определенного контекста представлена одним объектом.

Если User с id 125 уже загружен, повторный запрос может вернуть существующий объект вместо создания второго независимого экземпляра.

Так уменьшается риск противоречивого состояния объектов в памяти.

Change Tracking

Некоторые ORM отслеживают изменение свойств Model.

При Save Framework определяет, что именно было изменено, и формирует соответствующий UPDATE.

Change Tracking удобен, но большое количество отслеживаемых объектов может увеличивать потребление памяти.

ORM и кэширование

Некоторые ORM поддерживают различные уровни Cache.

Например, уже загруженный объект повторно используется внутри одной Session.

Дополнительный Cache может использовать Redis или другие системы.

Но кэширование требует стратегии актуализации и не должно скрывать изменения данных.

ORM и Pagination

Для больших списков ORM Query должен использовать Pagination.

Получать миллион Models в память Backend обычно неразумно.

Framework может формировать LIMIT, OFFSET или другой механизм постраничной выдачи в зависимости от СУБД.

ORM и Bulk Operations

Если нужно изменить сто тысяч строк, создание ста тысяч объектов и вызов save для каждого может быть слишком медленным.

ORM обычно предоставляет Bulk Insert или Bulk Update либо позволяет использовать Raw SQL.

Для массовых операций необходимо выбирать наиболее эффективный путь.

ORM и память

Преобразование строк базы в полноценные объекты имеет стоимость.

Если отчет получает сотни тысяч строк, ORM может потреблять значительно больше памяти, чем потоковая обработка простых значений.

Для тяжелой аналитики Model Objects часто не нужны.

ORM и производительность

ORM сама по себе не обязательно делает приложение медленным.

Проблемы чаще появляются из-за неверного использования: N+1, лишних Relations, отсутствующих индексов, больших выборок и слишком частых запросов.

Грамотно настроенная ORM может работать эффективно для большинства обычных Backend-сценариев.

Как измерять производительность ORM

Необходимо видеть количество SQL-запросов и их длительность.

Полезно отслеживать:

• Query Count;
• SQL Latency;
• N+1;
• объем возвращаемых строк;
• использование индексов;
• время транзакций;
• Connection Pool.

ORM и Observability

SQL-запросы ORM следует включать в общий мониторинг Backend.

OpenTelemetry Trace может показать HTTP Request и связанные Database Spans.

Так разработчик видит, что endpoint делает 150 SQL-запросов вместо ожидаемых трех.

ORM и логирование SQL

В development полезно включать логирование генерируемого SQL.

Это помогает изучить поведение ORM и быстро обнаружить N+1.

В production необходимо учитывать объем логов и чувствительные значения параметров.

ORM и Connection Pool

ORM обычно работает поверх Database Driver и Connection Pool.

Она берет соединение на время Query или Transaction и затем возвращает его в Pool.

Неправильное управление Session или Transaction может привести к исчерпанию доступных соединений.

Преимущества ORM

• меньше повторяющегося SQL-кода;
• удобный CRUD;
• работа с данными как с объектами;
• декларативные Relations;
• поддержка миграций;
• удобное управление транзакциями;
• параметризованные запросы;
• быстрая разработка типовых Backend-функций.

Недостатки ORM

• может скрывать неэффективный SQL;
• риск проблемы N+1;
• сложные Queries иногда трудно выразить;
• есть накладные расходы на создание объектов;
• специфические функции СУБД могут быть доступны не полностью;
• разработчик может перестать понимать устройство базы;
• абстракция усложняет диагностику без знания SQL.

Главная ошибка при использовании ORM

Наиболее опасный подход — воспринимать ORM как замену знания базы данных.

Framework может скрыть SQL-синтаксис, но не отменяет индексы, JOIN, транзакции, блокировки и Execution Plan.

Разработчик Backend должен понимать, что происходит на уровне СУБД.

Типичные ошибки ORM

1. Не смотреть генерируемый SQL.
2. Допускать N+1.
3. Загружать все Relations заранее.
4. Получать огромные списки без Pagination.
5. Не создавать индексы.
6. Использовать Model для тяжелой аналитики.
7. Держать Transaction слишком долго.
8. Использовать Raw SQL с небезопасной конкатенацией.
9. Автоматически применять опасные миграции в production.
10. Считать ORM полностью независимой от конкретной СУБД.

Как правильно использовать ORM

Шаг 1. Изучить SQL

Перед эффективной работой с ORM необходимо понимать SELECT, JOIN, индексы и транзакции.

Шаг 2. Правильно описать Relations

Связи должны соответствовать реальной реляционной модели.

Шаг 3. Контролировать Query Count

Endpoint не должен неожиданно выполнять сотни запросов.

Шаг 4. Использовать Eager Loading только при необходимости

Не следует загружать все Relations автоматически.

Шаг 5. Анализировать медленный SQL

Для критичных запросов проверяйте Execution Plan и индексы.

Шаг 6. Контролировать транзакции

Transaction Boundary должна соответствовать бизнес-операции.

Шаг 7. Версионировать миграции

Schema Changes должны храниться в Git и проходить Review.

Шаг 8. Использовать Raw SQL там, где это оправдано

ORM является инструментом, а не обязательным единственным способом доступа к данным.

Практический пример

Компания разрабатывает интернет-магазин на Backend Framework с ORM и PostgreSQL.

Models User, Product и Order соответствуют таблицам базы. Order связан с User через customer_id, а товары заказа — через отдельную Relation.

Разработчик создает endpoint со списком последних 100 заказов и выводит имя клиента для каждого заказа.

В первой версии ORM выполняет один Query заказов и еще 100 SELECT пользователей из-за Lazy Loading.

В Observability видно 101 Database Span.

Команда добавляет Eager Loading и получает пользователей вместе с заказами ограниченным количеством запросов.

После роста таблицы orders начинает замедляться фильтр по customer_id и created_at. Execution Plan показывает отсутствие подходящего индекса.

Команда добавляет Composite Index через Database Migration.

Таким образом ORM ускоряет разработку, но производительность достигается благодаря пониманию SQL и поведения СУБД.

ORM для бизнеса

Для бизнеса ORM помогает быстрее разрабатывать обычные функции информационной системы: пользователей, заказы, документы, справочники и другие CRUD-сценарии.

Стандартизированный Data Access Layer упрощает сопровождение проекта и снижает количество ручного SQL.

Но плохо используемая ORM способна создавать высокую нагрузку на СУБД и увеличивать стоимость инфраструктуры.

Поэтому выгода возникает тогда, когда команда сочетает удобство Framework с пониманием базы данных.

Когда стоит использовать ORM

• приложение использует реляционную базу;
• много типовых CRUD-операций;
• есть понятная Domain Model;
• нужно быстро развивать Backend;
• важны миграции Schema;
• команда использует стандартный Framework;
• необходим единообразный Data Access Layer.

Когда ORM может быть избыточной

Если сервис выполняет несколько очень специфических SQL-запросов, полноценная ORM может добавить ненужный слой абстракции.

Для аналитики, ETL и массовой обработки данных Query Builder или Raw SQL иногда проще и эффективнее.

В одном приложении вполне допустимо сочетать ORM для CRUD и ручной SQL для критичных сложных операций.

Связанные термины

Краткий итог

ORM — технология Object-Relational Mapping, которая связывает объекты приложения с таблицами реляционной базы данных. Разработчик работает с Models и Relations, а Framework преобразует действия в SQL.

ORM особенно полезна для CRUD, миграций, транзакций и типовых Backend-приложений. Она уменьшает количество повторяющегося кода и делает работу с данными ближе к объектной модели языка программирования.

При этом ORM не заменяет знания SQL. Для надежного production-приложения необходимо контролировать N+1, индексы, Execution Plan, количество запросов, Transaction Boundary и Connection Pool. Лучший результат обычно дает сочетание удобства ORM с осознанным использованием Query Builder и Raw SQL для сложных или критичных запросов.