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

Условия в приложении или в бд?

на уровне бд именно это решать

по идее sequelize в подобное не умеет

Если можно на уровне приложения решить, то просто собираю объект, который потом скормлю sequelize.

А в БД - уже от бд зависит. Вроде везде есть if, но с разным синтаксисом

Вот представь, у тебя есть юзер, в него аватрка, рейтинг, онлайн статус, геолакация, и еще что то там, и эти все данные тебе всегда нужны. Если у тебя сервис, возвращающий пользователя, он все это просто кеширует, а если запрос в бд, не важно один или несколько... это намного медленне.. тем более пользователь может месяцами ничего не менять, а ты все дергаешь и дергаешь..

Это - как раз очень простой случай. Это по сути просто сущность, хоть и связана с несколькими таблицами.
И хранить такое легко, потому что идентификатор один - ИД юзера.
Хотя уже тут надо думать об инвалидации.

А мне иногда надо по пришедшим мне параметрам (не один ИД, а куча параметров) вернуть условно результат обработки кучи таблиц, связанных М:М.

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

Не совсем так, юзера кешируем, если нужны посты юзера всегда можно вызвать postService.getPosts() будет пост кешировать или нет это его дело

юзер ничего не должен знать о постах

Надо для каждого работника некоторого подразделения (включая его подразделения всех уровней) получить список курсов, которые он должен пройти в этом году, чтобы выполнить нормы его должности, если известно, какие курсы он раньше проходил и за какие нормы они отвечают, а также требования к его профессии.
*упрощённый пример*
И это в целом просто выборка. А могут ещё быть запросы, где надо как-то непросто агрегировать / ранжировать и т.д.

Хороший пример - финтех.

Все привет. Может кто сталкивался с подобной проблемой. В инете не нашел инфы.
Прилага хоститься на google cloud. Хочу загрузить картинку, а file undefined\null, но если локальный запрос - все нормально загружается. В чем может быть проблема? Спасибо.

Учитывая исключения курсов, которые он проходил, которых условно может быть 1000, это в любом случаи сложный запрос, и для бд в том числе, единственная разница в том что не придется вытягивать ид в ноду. Если это страница, которая делает это при загрузке я бы в любом случаи смотрел в сторону оптимизации кэширования а закешировать там можно много всего. Если это просто фильтр, которым пользуются редко, ну тогда ок. Но опять же, админка это админка, там все немного по другому.

Я как бы не против эктив рекорд и т.д в некоторых случаях это удобно, когда есть модель, которая может все.. и везде, но чисто на почитать https://www.mehdi-khalili.com/orm-anti-patterns-part-1-active-record

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

Так это не про active record. Я ж говорю, даже, если бы у меня вообще не было ОРМ, и я всё сырыми запросами писал, всё равно были бы большие запросы)
Они ж не от ОРМ большие.

Нам дан замечательный инструмент - реляционные БД и SQL, с которыми можно отлично манипулировать данными, делая сложные операции. СУБД же разрабатываются так, чтобы эти операции работали быстро по мере возможности, не без кеширования и индексирования.

Зачем мне писать на JS процедурный код обработки данных, если можно записать декларативный запрос?

Ах, если бы это была правда, тогда бы и индексы никакие ставить не нужно было, но увы.. кэш в разы быстрее)

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

Ну и я так и не понял, как SQL запросы сложнее select from делают архитектуру плохой.

Приблизительно так и родился нест