Хранимые процедуры mySQL: преимущества и недостатки

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

Мое, не авторитетное, мнение:

Хранимые процедуры — это перенос части логики в БД. В некоторых случая может быть какой-то рост производительности, но в среднем можно сказать, что разница несущественная. Другой вопрос, что эту логику будет выполнять сервер db, а не сервер приложения, иногда это важно.

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

Так, что хранимые процедуры, в основном, ради удобства. В сайтах и веб-приложениях я пробовал делать все на процедурах, но в итоге практически полностью от них отказался, после нескольких доработок все уже не так красиво становится. Сейчас использую только в редких, специфических, случаях и, в основном, в связке с триггерами.

У меня опыт хранимых процедур для MySQL не большой (в MSSQL побольше, но как пользователь серверов большой принципиальной разницы не вижу), поэтому просто хочу поделиться мыслями. Не важно на чём вы пишете процедуры — на C++, JavaScript или SQL, но если у вас несколько технологий в проекте, то:

1. Каждую процедуру нужно писать в своей технологии.
2. Максимально изолировать технологии друг от друга (в идеале только передача параметров и результатов), чтобы держать проектирование под контролем.
3. Искать методы численной оценки производительности различных этапов программирования. Это отдельная задача.

Может у вас всё нормально идёт, и вы просто боитесь, что что-то пойдёт не так?

Хранимые процедуры и триггеры плохо поддерживаются универсальными ORM. Видимо из-за больших различий в разных РСУБД. Вот когда (если?) научатся транслировать DSL модели в конкретный диалект SQL и синхронизировать изменения с БД (а для «примитивных» — реализовывать на «обычном» ЯП), тогда и обретут второе дыхание.

хм… использование хранимых процедур в БД, где и как попало ни есть хорошо.

Был у нас один «архитектор», пришедший в WEB из Enterprise App, как-то в одном проекте мы впердолили 30% логики на хранимках. В итоге много ресурсов сожрал MySQL сервер, постоянный deadlock… отлаживать очень сложно, пришлось еще написать 15-20 % кода, для трейсинга выполнения хранимок…
ну и работать стало все медленнее. Когда я про это рассказал разработчикам Мускуля, они долго смеялись над построением такой архитектуры…

Так что, если использховать хранимки, то только в самых простейших случаях,
Мускуль — вам не Оракл, хоть он теперь и есть его младший братик…

в общем я бы сказал, что проект завалили, хотя он закрылся по причине финансирования (был кризис)…
но архитектор все равно оказался дураком, хотя хотел сделать как лучше