Когда писать длинную хранимую процедуру

Есть ли какие-либо рекомендации о том, когда вам следует и не следует писать длинную сложную хранимую процедуру из 2000 строк?

В моем конкретном случае эта хранимая процедура содержит множество операторов if / then, case, goto и ветвления. Он работает путем построения SQL-запросов в зависимости от входных данных и результатов запросов и использует оператор execute для выполнения построенных запросов.Он может выполнять несколько сконструированных запросов за один вызов и использует результаты этих запросов для построения других запросов для выполнения.

Это довольно запутанно и сложно для понимания. Отладка сложна, единственный способ узнать, что происходит, - пройти через вызов, чтобы увидеть, что он делает. Практически отсутствует обработка исключений или ведение журнала. Поддерживать это - боль. Фактически, никто на самом деле не знает, что он делает и как он был создан, и если бы нам пришлось внести в него изменения, нам пришлось бы принять подход «скрестите пальцы и надейтесь на лучшее». Но я думаю, что это было сделано так из соображений производительности.

Эта процедура используется во многих приложениях. Единственный другой способ сделать что-то подобное - это использовать веб-службу. Вероятно, он был бы сопоставим по сложности, но намного проще для понимания. Однако это, вероятно, будет в несколько раз медленнее, так как ему все равно придется делать несколько обращений к базе данных для 1 запроса.

Итак, мой вопрос (ы): как нам решить, когда и когда не писать длинные хранимые процедуры ?

Что-то мне не хватает, или мы просто должны мириться с нашей чудовищной хранимой процедурой?

Есть ли способы структурировать и разбить хранимые процедуры на более мелкие компоненты, чтобы их было легче понять?

Всегда ли хранимая процедура будет быстрее, чем что-либо еще, и будет ли она правильным выбором, если вам нужно сделать много вызовов к базе данных?