Est-ce qu'une procédure stockée qui appelle d'autres procédures stockées est mauvaise?

J'essaie de rendre une procédure longue stockée un peu plus gérable, Est-ce mal d'avoir une procédure stockée qui appelle d'autres procédures stockées par exemple je veux avoir un sproc qui insère des données dans une table et selon le type insert des informations supplémentaires dans la table pour ce type, quelque chose comme:

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

Ou est-ce quelque chose que je devrais gérer dans ma request?

Nous appelons procs d'autres procs tout le time. Il est difficile / impossible de segmenter une application nécessitant une database importante (ou une database uniquement).

L'appel d'une procédure depuis une autre procédure est parfaitement acceptable.

Cependant, dans Transact-SQL en s'appuyant sur @@ ERROR est enclin à l'échec. Exemple, votre code. Il échouera à détecter un échec d'insertion, ainsi que toute erreur produite dans les procédures appelées. C'est parce que @ ERROR est réinitialisé avec chaque instruction exécutée et ne conserve que le résultat de la toute dernière instruction. J'ai une input de blog qui montre un bon model de gestion des erreurs dans Transact-SQL et l'imbrication des transactions. Erland Sommarskog a aussi un article qui est, depuis longtime, la reference sur la gestion des erreurs dans Transact-SQL .

Non, c'est parfaitement acceptable.

Définitivement non.

J'ai vu des procédures stockées ginormous faire 20 choses différentes qui auraient vraiment bénéficié d'être refactorisé en plus petits, à but unique.

Tant qu'il se trouve dans le même schéma DB, il est parfaitement acceptable à mon avis. C'est la réutilisation qui est toujours favorable à la duplication. C'est comme appeler des methods dans une couche d'application.

pas du tout, je dirais même, il est recommandé pour les mêmes raisons que vous créez des methods dans votre code

Une procédure stockée appelant une autre procédure stockée est correcte. Juste qu'il y a une limite sur le niveau de nidification que vous pouvez aller.

Dans SQL Server, le niveau d'imbrication actuel est renvoyé par la fonction @@NESTLEVEL .

Veuillez consulter la section sur l' imbrication des procédures stockées ici http://msdn.microsoft.com/en-us/library/aa258259(SQL.80).aspx

à votre santé

Non. Il favorise la réutilisation et permet la fonctionnalité des composants.

Comme d'autres l'ont souligné, cela est parfaitement acceptable et nécessaire pour éviter la duplication des fonctionnalités.

Toutefois, dans Transact-SQL, faites attention aux transactions dans les appels de procédure stockée nesteds: Vous devez vérifier @@TRANCOUNT avant d'émettre une rollback transaction car elle @@TRANCOUNT toutes les transactions nestedes. Consultez cet article pour une explication détaillée.

Dans notre domaine informatique, nous utilisons des procédures stockées pour consolider le code commun des procédures stockées et des triggersurs (le cas échéant). Il est également pratiquement obligatoire pour éviter la duplication de sources SQL.

La réponse générale à cette question est, bien sûr, non – c'est une façon normale et même préférée de coder des procédures stockées SQL.

Mais il se pourrait que dans votre cas, ce ne soit pas une bonne idée.

Si vous conservez un set de procédures stockées prenant en charge le niveau d'access aux données (DAO) dans votre application (Java, .Net, etc.), le fait de disposer d'un niveau de database rationalisé et relativement mince bénéficierait à votre design globale. Ainsi, avoir un graphe étendu d'appels de procédures stockées peut en effet être mauvais pour maintenir et supporter la logique globale d'access aux données dans une telle application.

Je pencherais vers une dissortingbution plus uniforme de la logique entre DAO et le niveau de database de sorte que le code de procédure stockée s'insertait dans un seul appel fonctionnel.

Oui c'est mauvais. Alors que SQL Server prend en charge et permettre à une procédure stockée d'appeler une autre procédure stockée. J'essaierais généralement d'éviter cette design si possible. Ma raison?

principe de responsabilité unique

Ajoutant aux commentaires corrects d'autres affiches, il n'y a rien de mal en principe, mais vous devez surveiller le time d'exécution au cas où la procédure est appelée par exemple par une application externe qui se conforme à un timeout d'attente spécifique.

Exemple typique si vous appelez la procédure stockée à partir d'une application Web : lorsque le timeout d'expiration par défaut intervient car votre string d'exécutions prend plus de time, vous obtenez un échec dans l'application Web même lorsque la procédure stockée est correctement validée. Il en va de même si vous appelez d'un service externe. Cela peut entraîner un comportement incohérent dans votre application, déclenchant des routines de gestion des erreurs dans les services externes, etc.

Si vous êtes dans des situations comme celle-ci, je brise la string d'appels en redirigeant les appels d'enfants à exécution longue vers des process différents en utilisant un Service Broker .