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

Question

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

BEGIN TRANSACTION

        INSERT INTO dbo.ITSUsage (
            Customer_ID,
            [Type],
            Source
        ) VALUES ( 
            @Customer_ID,
            @Type,
            @Source
            )
    SET @ID = SCOPE_IDENTITY()  

    IF @Type = 1
        BEGIN
                  exec usp_Type1_INS @ID, @UsageInfo 
            END
        IF @TYPE = 2
                BEGIN
                  exec usp_Type2_INS @ID, @UsageInfo 
            END

    IF (@@ERROR <> 0)
        ROLLBACK TRANSACTION
    ELSE
        COMMIT TRANSACTION      

Или это то, что я должен обрабатывать в своем приложении?

Answer 1

Общий ответ на этот вопрос, конечно же, Нет - это нормальный и даже предпочтительный способ кодирования хранимых процедур SQL.

Но, возможно, в вашем конкретном случае это не очень хорошая идея.

Если вы поддерживаете набор хранимых процедур, поддерживающих уровень доступа к данным (DAO) в вашем приложении (Java, .Net и т. Д.), Тогда уровень базы данных (давайте назовем хранимые процедуры таким образом) упорядоченным и относительно тонким принесет пользу Общий дизайн. Таким образом, наличие обширного графика вызовов хранимых процедур действительно может быть плохим для поддержания и поддержки общей логики доступа к данным в таком приложении.

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

Answer 2

В нашей области ИТ мы используем хранимые процедуры для консолидации общего кода как для хранимых процедур, так и для триггеров (где это применимо). Это также практически необходимо для избежания дублирования исходного кода SQL.

Answer 3

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

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

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