не красиво

такая вот жизнь без рефлекшона и кодгена

а еще легко ошибиться в названии поля)

тогда уж лучше во встроенных процедурах большую часть кода писать и оттуда запускать

хранимки тоже такое на самом деле

и не везде применимы

я в смысли лучше чем такое

кстати видел видео где рассказывалось что хранимые процедуры надо ко всем обращениям в базу делать чтобы разделять логику и модель, а далее набирается архитектор БД и он уже как хочет меняет эти процедуры, таким образом можно менять ему как угодно структуру базы а у программиста будет всегда единое API некое, так же это разграничивает степень ответственности когда доступ к данным у одного человека а не у +100500 . И собвственно если будет слив данных все узнают кто это делает.

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

ну этот подход тоже имеет кучу минусов

какие?

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

ну это крайне редко происходит же и потому этим можжно принебречь в угоду удобности

иногда нужно вытянуть инфу на апп слой, как-то обработать и на основе этой обработки тянуть что-то еще

тут мне удобнее было бы все на апп слое сделать тоже

да и экономнее, чем 100500 реквестов посылать

несколько процедур

дорого гонять данные туда-сюда

если мне там нужно на основе большого массива данных решение принять?

нуда, лишние запросы иногда, но тут выбирать удобство или полная производительность