Comment créer plusieurs procédures stockées en utilisant SQL

Question

J'ai une fonction vb.net qui crée plusieurs procédures stockées basées sur les paramètres transmis dans la fonction. Je veux déplacer ce vb.Net dans un seul fichier SQL (pour des raisons de maintenance) mais je ne suis pas sûr de savoir comment le recréer en SQL sans créer 7 procédures stockées séparées.

Je crée un total de 20 procédures stockées et je ne veux pas vraiment en créer autant dans un fichier SQL car la maintenance sera un cauchemar. Je me demande s'il y a une solution similaire à la façon dont je l'ai fait VB.Net ci-dessous:

Private Sub CreateStoredProcedures() 

     CreateSP("SummaryNone", "YEAR([sale].[DateTime])") 
     CreateSP("SummaryUser", "[sale].[User]") 
     CreateSP("Summarysale", "[sale].[sale]") 
     CreateSP("SummaryBatch", "[sale].[Batch]") 
     CreateSP("SummaryDay", "dbo.FormatDateTime([sale].[DateTime], 'yyyy-mm-dd')") 
     CreateSP("SummaryMonth", "dbo.FormatDateTime(dbo.DateSerial(YEAR([sale].[DateTime]), MONTH([sale].[DateTime]), 1), 'yyyy-mm-dd')") 
     CreateSP("SummaryYear", "Year([sale].[DateTime])") 

     Return 
    End Sub 


    Private Sub CreateSP(ByVal vName As String, ByVal vGroup As String) 

     Dim CommandText As String = _ 
         "CREATE PROCEDURE " & vName _ 
         & " @StartDate varchar(50)," _ 
         & " @EndDate varchar(50)" _ 
         & " AS " _ 
         & " SELECT " & vGroup & "     AS GroupField," _ 
         & " Sum([Project].[NumProject])    AS TotalProject," _ 
         & " Sum([Project].[Title])     AS SumTitle," _ 
         & " Sum([Project].[Duration])    AS SumDuration," _ 
         & " Sum([Project].[Info])    AS SumInfo," _ 
         & " Sum([Customer].[NumCustomer]) AS TotalNumCustomer," _ 
         & " Sum([Orders].[NumOrders]) AS TotalNumOrders," _ 
         & " Sum([OrderInspection].[NumInspects])   AS TotalNumInspects," _ 
         & " Sum([OrderInspection].[NumFails])    AS TotalNumFails," _ 
         & " Sum([CustomerInspection].[NumInspects]) AS TotalNumCustomerInspectionInspects," _ 
         & " Sum([CustomerInspection].[NumFails])  AS TotalNumCustomerInspectionFails," _ 
         & " Sum([Measurements].[NumMeasurements]) AS TotalNumMeasurementss" _ 
         & " FROM ((((((sale LEFT JOIN Project ON [sale].[saleId]=[Project].[saleId])" _ 
          & " LEFT JOIN Customer ON [Project].[PrintId]=[Customer].[PrintId])" _ 
          & " LEFT JOIN Orders ON [Project].[PrintId]=[Orders].[PrintId])" _ 
          & " LEFT JOIN OrderInspection  ON [Project].[PrintId]=[OrderInspection].[PrintId])" _ 
          & " LEFT JOIN CustomerInspection ON [Project].[PrintId]=[CustomerInspection].[PrintId])" _ 
          & " LEFT JOIN Measurements ON [Project].[PrintId]=[Measurements].[PrintId])" _ 
         & " WHERE [sale].[DateTime] BETWEEN dbo.FormatDateTime((@StartDate), 'yyyy-mm-dd')" _ 
         & " AND dbo.FormatDateTime((@Enddate),'yyyy-mm-dd')" _ 
         & " GROUP BY " & vGroup & "" _ 
         & " ORDER BY " & vGroup & ";" 

     SqlExecuteNonQuery(CommandText) 

     return 
    End Sub 

Je me réjouis de vos commentaires et réponses.

Merci

Answer 1

Vous pouvez stocker un modèle dans un fichier texte en tant que ressource incorporée dans votre DLL .NET. Avoir des espaces réservés pour vos bits dynamiques. Ce qui rendrait votre solution actuelle beaucoup plus facile à maintenir. Ensuite, vous chargez le flux à partir de la DLL et conservez votre implémentation actuelle.

L'édition du fichier texte est plus facile que le gros morceau de SQL qui est incorporé dans votre fichier C#.

Vous obtiendrez probablement un succès de performance si vous déplacez cela vers un seul proc, vous pouvez être heureux avec lui mais gardez à l'esprit que le proc aura également quelques problèmes de maintenance. Nous aimons généralement éviter le SQL dynamique dans les procs stockés. Et une branche IF à 7 voies est un cauchemar de maintenance.

Answer 2

Je vous recommande de créer une seule procédure stockée que vous appelez. Puis, utilisez le SQL dynamique pour créer l'instruction select appropriée à utiliser dans la procédure stockée unique.

Avez-vous du sens?

Answer 3

Vous pouvez créer une seule procédure stockée appelée Résumé, puis transmettre le nom et la colonne en tant que paramètres supplémentaires. Ensuite, vous créez un SQL dynamique et l'exécutez.

Answer 4

Construire l'instruction dynamiquement et ensuite l'exécuter (en T-SQL) est votre meilleur pari, à mon avis. Je voudrais aussi échapper à la création de procs stockés dans le code si tout pissoble. Le plus grand avantage d'avoir stocké porcs est que leurs plans d'exécution sont mis en cache sur le serveur. Si vous les supprimez et les recréez souvent, ces plans sont supprimés car le processus est supprimé.

Answer 5

L'avantage d'un SP est qu'il est pré-compilé et qu'un plan d'exécution a déjà été créé en gardant à l'esprit les données présentes au moment de la création du SP. Par conséquent, un SQL dynamique aurait des implications en termes de performances car SQL Server ne peut pas savoir à l'avance quels index utiliser (ou même les utiliser ou non). Puisque vous créez actuellement le sp après la substitution, le plan de requête est créé correctement. Ce ne sera pas le cas après avoir basculé vers SQL dynamique.

Vous pouvez également créer un sp avec if si condition pour prendre en charge les différents scénarios. Cependant, cela nécessite une maintenance au cas où plus de paramètres seraient ajoutés plus tard.