ORM — звучит красиво: пишешь классы, аннотации, а база сама как-то живёт. Но на практике — это как ездить закрытыми глазами на машине на автопилоте
🐗 1. Query Builder делает ровно то, что ты просишь
Query Builder — это тонкая обёртка над SQL.
Ты чётко контролируешь какой запрос пойдёт в базу, какие JOIN’ы выполняются и какие поля читаются.
Он не “угадывает”, что ты хотел сделать — он просто выполняет твой запрос
С Query Builder:
await db('users')
.select('id', 'email')
.where('is_active', true);
SQL под капотом — предсказуемый:
SELECT id, email FROM users WHERE is_active = true;
А ORM может внезапно решить “загрузить” связи, добавить лишние поля или сделать 3 подзапроса вместо одного.
Ты думаешь, что сделал findOne, а реально — отправил 5 SQL-запросов
🍆 2. Работа с данными — это высокие риски
База данных — сердце системы.
Если ты не понимаешь, какой SQL реально выполняется, ты не контролируешь производительность и целостность данных
ORM часто скрывает логику за “удобным” API, но любая сложная операция превращается в дебри.
Query Builder же заставляет мыслить на уровне SQL, а не на уровне магии “entities” и “relations”
🙂 3. Меньше магии — меньше проблем
TypeORM, Sequelize, Prisma — все они в какой-то момент начинают диктовать свои правила.
Тебе нужно не просто “сделать запрос”, а ещё угадать, как ORM это интерпретирует
• Миграции — можно и нужно писать руками. Так надёжнее
• Сущности (Entity) в TypeORM — часто мешают, особенно когда структура БД не совпадает 1:1 с моделями кода
• При изменениях в схеме ORM может внезапно удалить или пересоздать таблицу, если ты где-то забыл флаг
😱 4. Иногда ORM тоже нормик
ORM удобно, пока проект маленький и нужно собрать быструю гипотезу на коленке
🚀 Пост Guru Node.js: @DemetraIT