Stored procedure

Questa voce o sezione sull'argomento basi di dati non cita le fonti necessarie o quelle presenti sono insufficienti.

Una stored procedure (lett. "procedura memorizzata" in italiano), nota anche semplicemente come procedura o funzione,^[1]^[2] è un programma conservato all'interno di un database ed eseguito dal DBMS associato. Vengono principalmente utilizzate come mezzo per massimizzare il riuso di codice relativo a operazioni di amministrazione e manipolazione dei dati, oltre che indebolire l'accoppiamento tra una database e le applicazioni che lo utilizzano, risultando in un sistema complessivamente più robusto.^[3]

La maggior parte dei DBMS supporta l'uso di diversi linguaggi di programmazione per la scrittura delle procedure.^[2] A parte SQL e dialetti proprietari, essi possono essere divisi in due categorie: linguaggi general-purpose^[4] e linguaggi procedurali dedicati.^[5]

Alcuni DBMS^[quali?] consentono di criptare le stored procedure. Questa pratica viene usata dai produttori di software per fare in modo che il cliente non possa leggerle. Questo modo di distribuire il software è detto closed source, il cui codice cioè deve restare segreto per evitare che venga studiato o modificato.

Tipologie

Generalizzando, a seconda delle loro caratteristiche si distinguono diversi tipi di procedure:

Funzioni	restituiscono un singolo valore oltre ad accettare parametri di ingresso e/o uscita
Procedure	non restituiscono valori ma accettano parametri di ingresso e/o uscita
Trigger	sono attivati da eventi

Linguaggi

I linguaggi utilizzabili per la scrittura delle stored procedure sono molti e dipendono dal DBMS che si utilizza. I più diffusi sono sicuramente Java e C/C++. I DBMS offrono anche versioni strutturate di SQL in modo che possa essere utilizzato per scrivere procedure che contengano condizioni e cicli. I più famosi sono:

PL/pgSQL (PostgreSQL)
PL/SQL (Oracle)
PL/I (DB2)
Transact-SQL (SQL Server)

Estensioni procedurali di SQL

Sebbene lo standard SQL:2003 preveda diversi costrutti che fanno di SQL un linguaggio procedurale, i DBMS che implementano le Stored Procedure tendono a utilizzare estensioni specifiche, o a basarsi sulle implementazioni più diffuse anziché sullo standard. A ciò si aggiunge il fatto che i DBMS più leggeri non implementano affatto le Stored Procedure o altri tipi di routine. Per questi motivi, i costrutti procedurali sono quella parte dell'SQL più soggetta a variazioni quando si passa da un dialetto all'altro.

Le estensioni procedurali di SQL comprendono:

costrutti per il controllo del flusso;
- controllo condizionale;
- cicli;
cursori;
gestione degli errori.

Vantaggi e svantaggi

I principali vantaggi che derivano dall'utilizzo delle stored procedure sono i seguenti:

La stored procedure evita al client di riscrivere query complesse offrendo la possibilità di richiamare una procedura archiviata all'interno del database.
Di conseguenza anche il numero di informazioni che saranno scambiate tra client e server sarà minore a tutto vantaggio delle prestazioni.
Trattandosi di linguaggi strutturati, diventano possibili elaborazioni complesse non altrimenti realizzabili usando unicamente query SQL.
La compilazione di una stored procedure avviene una volta sola, al suo inserimento. Ogni volta che la procedura viene richiamata viene semplicemente eseguita e questo aumenta significativamente le prestazioni.
L'utilizzo di stored procedure permette di mantenere librerie di funzioni da utilizzare all'interno del database stesso. Potenzialmente si potrebbe eseguire ogni operazione richiamando una diversa procedura, senza conoscere la struttura di un database magari complesso, o avendone una conoscenza limitata.
Proprio per questo motivo, l'amministratore di database può a volte evitare di concedere i permessi di modifica o di lettura su molte tabelle a determinati utenti, concedendo semplicemente il permesso di eseguire le stored procedure.

Gli svantaggi principali sono invece i seguenti:

Le stored procedure aumentano il carico di lavoro per il server.
A volte non si può utilizzare il linguaggio che si vorrebbe utilizzare, perché il DBMS non lo supporta.

Note

^ (EN) User-Defined Procedures, su postgresql.org. URL consultato il 3 luglio 2024.
^ ^a ^b (EN) User-Defined Functions, su postgresql.org. URL consultato il 3 luglio 2024.
^ Atzeni 2018.
^ (EN) C-Language Functions, su postgresql.org. URL consultato il 3 luglio 2024.
^ (EN) Procedural languages, su postgresql.org. URL consultato il 3 luglio 2024.

Bibliografia

Paolo Atzeni, Stefano Ceri, Piero Fraternali, Stefano Paraboschi e Riccardo Torlone, Basi di dati, 5ª ed., Milano, McGraw-Hill, 2018, ISBN 978-88-386-9445-5.