Stored Procedure in SQL Server

Le stored procedure sono un insieme precompilato di istruzioni T-SQL archiate per nome ed elaborate come le funzioni dei linguaggi di programmazione. I vantaggi di questo modo di operare sono molteplici, la notevole velocità di esecuzione delle istruzioni SQL perché queste procedure sono compilate al primo utilizzo e poi richiamate, quindi, come avviene per la piattaforma .NET, la seconda volta che una funzione viene richiamata è notevolmente più veloce della prima esecuzione. Altri vantaggi, tramite le chiamate a queste vere e proprie funzioni, sono il mascheramento della complessità del database, una condivisione della logica dell’applicazione ed una marcata diminuzione del traffico di rete. Noi di RGPSoft abbiamo dotato il nostro software gestionale Vikings della possibilità di connessione al Server SQL di Microsoft, anche se non lo abbiamo dotato di chiamate a stored procedure per via del poco utilizzo che se ne fa di questo server in ambito di piccola impresa, tra i nostri progetti vi è appunto anche quello di specializzare i nostri applicativi per SQL Server, lavoro che non dovrebbe costare molto tempo.

Alla creazione di una stored procedure, SQL Server verifica la sintassi ( parsing ) e poi memorizza il nome dell’oggetto in sysobjects del database attivo, il codice della stored procedure in syscomments, dove può essere direttamente modificato tramite il Query Analyzer. Quindi SQL Server verifica solo la sintassi della stored procedure e soltanto dopo, a tempo di compilazione, verificherà che ci siano tutti gli oggetti; questo comportamento prende il nome di Delayed Name Resolution.

Come in tutti gli altri linguaggi di programmazione, anche T-SQL permette di passare parametri alle stored procedure ed assegnare a questi dei valori di default che si utilizzeranno se non viene specificato un valore a tempo d’esecuzione. Altra cosa da notare è che i parametri possono essere passati sia in modo posizionale che nominativo. Nel primo caso i parametri sono specificati secondo l’ordine in cui sono stati dichiarati, mentre nel secondo caso vengono richiamati con il nome della dichiarazione.

CREATE PROCEDURE dbo.Ordini
@idOrdine  INT = 0,
@strRagSoc NVARCHAR(100) = NULL
AS
SET NOCOUNT ON
IF (@idOrdine > 0) BEGIN
 SELECT * FROM Ordini
 WHERE IDOrdine = @idOrdine AND RagSoc = '@strRagSoc'
 ORDER BY RagSoc
END

Questo qui sopra è soltanto un esempio esplicativo sull’uso delle stored procedure ed in particolare abbiamo inserito parametri di input ed una semplice condizione. Al momento dell’esecuzione si devono assegnare i valori desiderati altrimenti vengono considerati quelli di default.

EXEC Ordini @idOrdine = 10, @strRagSoc = ‘Rossi’

Possiamo anche utilizzare parametri di output, basta assegnare alla variabile la keyword OUTPUT, vediamone un esempio.

CREATE PROCEDURE dbo.TotOrdine
@idOrdine  INT = 0,
@mTot MONEY OUTPUT
AS
SET NOCOUNT ON
IF (@idOrdine > 0) BEGIN
 SELECT @mTot = SUM(Prezzo * Qt)
 FROM Ordini
 WHERE IDOrdine = @idOrdine
END

Come potete osservare le stored procedure sono estremamente potenti e permettono di delegare i calcoli nell’archivio dati, al server, quindi non intasare la rete con pacchetti di domanda e risposta. Quello che abbiamo spiegato in questo articolo è soltanto un assaggio della programmazione con il linguaggio T-SQL, se volete che approfondiamo l’argomento potete segnalarcelo nel forum o nei commenti.