Здравствуйте, Gattaka, Вы писали:

G>Коллеги,
G>Так ли плохо реализовывать бизнес логику в высокопроизводительных хранимых процедурах? Либо сейчас модно использовать кодогенераторы типа ОРМ, которые генерируют ужасные sql запросы? Учитывая, что код на sql как правило более локаничный и лучше читается.

Про фэн-шуй не будем, это и без меня расскажут. С практической точки зрения — ну можно, да. При наличии определённых условий, разумеется.

1. Проект долгоживущий, сознательно завязан на определённую РСУБД и не планирует мигрировать в облако "как-нибудь потом". Если тут объяснения нужны — дополню.
2. Скрипты хранятся вместе с прочими исходниками (отдельным проектом, разумеется) и проверяются по тем же принципам — тесты, билд-сервер, скрипты миграции с обязательной проверкой деплоем на предыдущие выпущенные версии и тыды и тыпы.
3. В скриптах лежит только то, что туда действительно имеет смысл выносить. Тупо перегонять всю БЛ на сторону СУБД неэффективно во всех смыслах, что по поддержке, что по производительности.

Ну а что именно паковать в скрипты — родной sql, хранимки или view — эт уже на усмотрение разработчиков.