Существуют ли какие-либо рекомендации относительно того, когда следует и не следует писать длинную сложную хранимую процедуру длиной более 2000 строк?
В моем конкретном случае эта хранимая процедура содержит множество операторов if / then, case, goto и branching.Он работает путем построения запросов SQL в зависимости от входных данных и результатов запросов и использует оператор execute для запуска построенных запросов.Он может выполнять несколько построенных запросов за один вызов и использовать результаты этих запросов для создания других запросов для выполнения.
Это довольно грязно и трудно понять.Отладка сложна, единственный способ узнать, что происходит, - это пройти вызов и посмотреть, что он делает.Там почти нет обработки исключений или регистрации.Поддержание это боль.На самом деле, никто на самом деле не знает, что он делает или как он был создан, и если бы нам пришлось вносить в него изменения, нам пришлось бы придерживаться подхода «скрестить пальцы и надеяться на лучшее».Но я думаю, что это было сделано из соображений производительности.
Эта процедура используется многими приложениями.Единственный другой способ сделать что-то подобное - это веб-сервис.Вероятно, это будет сопоставимо по сложности, но намного проще для понимания.Тем не менее, это, вероятно, будет в несколько раз медленнее, поскольку все равно придется совершать несколько вызовов в базу данных для одного запроса.
Итак, мой вопрос (ы): как мы решаем, когда и когда не писатьдолго хранимые процедуры?
Есть ли что-то, чего я упускаю, или нам просто нужно мириться с нашей чудовищной хранимой процедурой?
Существуют ли способы структурировать и разбивать хранимые процедуры на более мелкие компоненты, чтобы их было легко понять?
Будет ли хранимая процедура всегда быстрее, чем что-либо еще, и будет ли правильным выбором, когда вам нужно сделать много обращений к базе данных?