Для моих читателей, кто возможно не застал этот интересный концепт, немного археологии. Хранимые процедуры имплементируют порядок выполнения в языке подобном языку запросов и позволяют реализовать бизнес-логику на уровне хранилища (чаще всего реляционного). То есть наши любимые
SELECT * FROM bar WHERE foo = 1; можно было завернуть в LOOP и даже применить IF.Из плюсов - у "хранимок" много вычислительных ресурсов (серверы СУБД нередко очень большие), отсутствуют сетевые задержки и имеется практически прямой доступ к данным. Оптимизировать их по производительности приходится редко, разве что нужно уметь в эффективный SQL, да насоздавать индексов, где положено.
Из минусов - их довольно тяжело тестировать без реальных данных, очень сложно журналировать и отслеживать их корректное выполнение, обработка исключений опять же на РСУБД.
По моим наблюдениям, инженеры стали избегать ХП с момента развития NoSQL и появления новых видов хранилищ данных (ключ-значение, колоночные, документные)... Чего греха таить, многие разработчики и SQL-то не знают и не хотят учить. Тем не менее, разработчики РСУБД обязательно включают ХП в список функционала, чтобы не отказываться от определенных ниш рынка (банковский сектор, госструктуры и т.д.).
И все же больше всего меня интересует переход. Если я правильно понял прочитанное, контора реализовала новую архитектуру за полгода (если это правда, это круто), но избавилась от бОльшей части своего персонала. Массовый исход понятен - перенос исполнения из зоны PHP в зону PostgreSQL требует других компетенций, текущая команда могла попросту не потянуть.
Но у меня все же вопрос - какую проблему все таки решало руководство? Точно ли дело в медленном развитии платформы?