если мы говорим о перфомансе - то БД-шный функции вроде как выигрывают, но размазывается бизнес логика, что повлияет на понимание целостности системы (без нормально поддерживаемой документации, на которую тоже силы нужно тратить)
поясню бекграунд на всякий случай я сейчас перехожу из фронтенда во бекенд проект чисто мой учебный
допустим есть таблица у которой есть связи (1:м) с таблицей б которая связана (1:м) с таблицей в
и допустим я хочу удалить одним действием запись в таблице б это значит что мне для начала надо удалить все связанные записи из таблицы в и связь в таблице а
а насчет бизнеслогики, то она все же будет не на pgplsql на оном я хочу писать все полностью связанное с добавлением, удалением и вытаскиванием п.с. для связи с базой использую node-postgres
Плюсы по сравнению с писанием прямо в базе: - очевидность - этот запрос попадает в version control соответственно видно кто и когда его менял - если большая команда то тоже - такие запросы ревьювятся вместе с кодом
Плюсы по сравнению с писанием прямо в базе: - очевидность - этот запрос попадает в version control соответственно видно кто и когда его менял - если большая команда то тоже - такие запросы ревьювятся вместе с кодом
если в базе - вы слегка подзамучитесь потом писать миграции которые меняют эти функции. насколько я помню там приходится дропать функцию и как бы создавать ее заново.
здесь вот pros/cons https://www.postgresqltutorial.com/introduction-to-postgresql-stored-procedures - Slowness in software development because stored procedure programming requires specialized skills that many developers do not possess. - Difficult to manage versions and hard to debug. - May not be portable to other database management systems e.g., MySQL or Microsoft SQL Server.
Для практики на своем проекте почему бы и не поиграться. Чтобы уметь это делать.
для pg что ли нет варианта хранимки хранить в vcs и накатывать их на живую базу? в mssql, например, это стандартный flow, и там код на транзакте точно так же проходит ревью
в текущем проекте sequelize (исторически сложилось) и миграции от него же, типа sequelize db:migrate. к миграциям у меня претензий нет, там внутри 2 функции - up и down - и внутри мы пишем сырые SQL запросы. а сам sequelize как многие ORM генерит местами ужасные запросы под капотом, если его средствами делать джойны