Comments 11
Кажется пропущен пример JS для запроса:
SELECT * FROM persons WHERE firstName = 'Ben' ORDER BY age;
В оригинале он такой:
const persons = await Person.query()
.where({ firstName: 'Ben' })
.orderBy('age');
сравнительно молодая и минималистичная ORM-библиотека для Node.js
7 лет назад первые публикации пакета появились в npm, не такая уж и молодая. На год старше того же TypeOrm. Как раз на проекте исторически сложился Objection, с приходом NestJs как раз заглядываюсь на TypeOrm.
когда в приложении много таблиц с большим количеством связей, которые нужно определить, и выполнить несколько объединенных запросов
вот по моему опыту, как раз когда в приложении много данных, по разным таблицам, и есть ложные связи, вот именно тогда лучше всего самим писать SQL запросы, потому что, что там нагенерирует эта ORM большой большой вопрос.
Ну нужно понимать, что нет серебрянной пули. Если запросы, создаваемые ORM будут мешать жить, то можно залезть и отпрофилировать и заменить на нативные запросы. Другое дело, что во время разработки зачастую важна скорость создания фичи, а оптимизацией можно заняться потом (то есть никогда :D)
Полностью согласен
как раз для минимизации кода и ускорения его написания
для простых запросов ORM это чудо.
Но как только касается кучи инклудов с точной выборкой + сортировкой по доп полю
то написать баг через ORM очень просто.
А не лучше наоборот, если приложение большое, запросы сложные и много данных, не использовать orm? Получается мы тянем в js код промежуточные данные?
Prisma топ 🔥
Как упростить работу с базами данных в Node.js с помощью Objection.js