4.10. Проблемы ORM
Разработчику
Аналитику
Тестировщику
Архитектору
Инженеру
Проблемы ORM
Проблема несоответствия парадигм
★ Проблема несоответствия парадигм (Object-Relational Impedance Mismatch) возникает из-за различий между объектно-ориентированной моделью и реляционной моделью. Эти две модели работают по-разному, и их перевод друг в друга требует дополнительных усилий.
Какие различия проблемны?
- Структура данных. В ООП данные организованы в виде объектов с методами, а в реляционных БД в виде таблиц с фиксированной структурой.
- Отношения. В ООП отношения реализуются через ссылки или композицию, а в реляционных БД отношения реализованы через внешние ключи и JOIN-операции.
- Идентификация объектов. В ООП объекты уникальны благодаря ссылкам на них в памяти, а в БД уникальность обеспечивается первичными ключами.
- Наследование. В ООП поддерживается наследование классов, тогда как в реляционных БД наследование нужно эмулировать.
- Типизация. В ООП типы данных строгие и могут быть сложными (например, пользовательские классы), тогда как в реляционных БД типы данных ограничены стандартными (INT, VARCHAR).
Это порождает фундаментальные отличия. К примеру, в классе User есть метод getFullName(), который объединяет имя и фамилию пользователя. В ООП это просто метод объекта, тогда как в реляционной БД придётся выполнить SQL-запрос SELECT с использованием конкатенации CONCAT.
Преимущества и недостатки
Конечно, преимущества ORM значительнее - упрощение работы с БД, переносимость между разными СУБД, автоматизация, безопасность, ускорение процесса разработки.
Но недостатки ORM тоже существуют:
- производительность - автоматически сгенерированные запросы могут быть менее эффективными, чем ручные;
- ограниченная гибкость - сложные запросы (например, с множеством JOIN-операций) могут быть трудно реализуемы через ORM;
- обучение - необходимо изучить ORM, что может быть непростой задачей для новичка;
- риск «магии» - разработчики могут не понимать, какие именно SQL-запросы генерировать ORM.
К примеру, аналитик, который поставит задачу разработчику, мог руководствоваться знанием SQL, и для себя он мог сделать огромный запрос, который успешно даёт результат. Но учитывая объем запроса и множество подзапросов, объединений и прочего функционала, разработчику может быть довольно сложно реализовать ту же логику через ORM, из-за чего может возникнуть недопонимание, мол, «чего тут такого сложного?».
ORM - мощный инструмент, но не всегда подходит. Он не подойдёт для систем со сложными аналитическими запросами, систем с высокой нагрузкой, необходимостью полного контроля и при использовании нестандартных или специализированных баз данных.
Альтернативы
★ Альтернативами ORM являются:
- «Сырой» SQL - написание SQL-запросов вручную;
- Query Builders - инструменты, которые позволяют строить SQL-запросы программно (Knex.js в JavaScript, SQLAlchemy Core в Python);
- Data Mappers - инструменты, которые разделяют объектную модель и БД (Dapper в C#, MyBatis в Java);
- NoSQL - использование нереляционных баз данных, например, MongoDB, Redis.
Но в крупных системах подходы могут комбинироваться.
К примеру, в интернет-магазине ORM для управления каталогом товаров, Query Builder для сложных фильтров товаров, сырой SQL для аналитических отчётов о продажах, а NoSQL для хранения временных данных. Надо решить какую-то проблему и сделать выполнение сложной комбинации в PostgreSQL, к примеру, связанной с материализованным представлением - для этого выполняется прямой запрос. И порой в коде можно встретить сырые SQL.
Поэтому, если возникла проблема несоответствия парадигм, можно комбинировать решения.