ORM і доступ до бази даних: об’єкти замість SQL – плюси й мінуси

Коротко: ORM відображає таблиці бази даних на об’єкти, тож дані запитуються кодом замість SQL; це заощаджує написання, але може коштувати продуктивності та розуміння.

Докладніше: ORM означає об’єктно-реляційне відображення (object-relational mapping): таблиці стають класами, рядки — об’єктами, стовпці — властивостями. Приклади: Hibernate/JPA (Java), Entity Framework (C#), SQLAlchemy та Django ORM (Python), Prisma, Drizzle, TypeORM (JavaScript/TypeScript), ActiveRecord (Ruby), Eloquent (PHP).

Подробиці

Приклад

// Drizzle (TypeScript)
const active = await db
  .select()
  .from(users)
  .where(and(eq(users.active, true), gt(users.age, 17)))
  .orderBy(users.name)
  .limit(10);

Інструмент перетворює це на SQL з параметрами (захист від SQL-ін’єкцій), виконує його й повертає типізовані об’єкти. Підтримуються також міграції схеми та зв’язки (1:n, n:m).

Переваги

• Менше шаблонного коду: немає ручного відображення рядків на об’єкти.
• Типобезпека й автодоповнення в редакторі.
• Безпека: параметризовані запити за замовчуванням.
• Міграції, зв’язки, валідація.
• Код, незалежний від бази даних (у межах).

Недоліки та підводні камені

• Проблема N+1: для кожного об’єкта виконується ще один запит (список замовлень плюс по одному запиту для клієнтів). Рішення: eager loading (JOIN, include, joinedload).
• Бездумні запити: завантажуються всі стовпці, величезні обсяги в пам’яті.
• Протікаюча абстракція: складний аналіз, віконні функції, спеціальні функції важко виразити; тоді чистий SQL.
• Крива навчання ORM на додачу до SQL; щоб оцінювати продуктивність (індекси, EXPLAIN), все одно потрібно розуміти SQL.
• Магія (ліниве завантаження, неявні транзакції) призводить до несподіваної поведінки.

ORM чи SQL?

ORM — для повсякденних операцій CRUD, небагатьох складних запитів. Побудовники запитів (Kysely, jOOQ, Knex) — золота середина: близько до SQL, але типобезпечно. Чистий SQL — для звітів, аналізу, вузьких місць продуктивності. Дивіться згенеровані запити SQL (журналювання), плануйте індекси та міграції свідомо. Хто знає SQL, краще використовує ORM.

Див. також: Проблема N+1, SQL-ін’єкція, Міграція бази даних, Транзакції та ACID