Le stored procedure sono un batch di istruzioni SQL che possono essere eseguite in due modi. La maggior parte dei principali DBM supporta stored procedure; tuttavia, non tutti lo fanno. Dovrai verificare con la tua particolare documentazione di aiuto DBMS per i dettagli. Poiché ho più familiarità con SQL Server, lo userò come campioni.
Per creare una stored procedure la sintassi è abbastanza semplice:
CREATE PROCEDURE <owner>.<procedure name>
<Param> <datatype>
AS
<Body>
Quindi ad esempio:
CREATE PROCEDURE Users_GetUserInfo
@login nvarchar(30)=null
AS
SELECT * from [Users]
WHERE ISNULL(@login,login)=login
Un vantaggio delle procedure memorizzate è che è possibile centralizzare la logica di accesso ai dati in un unico luogo che è quindi facile da ottimizzare per i DBA. Le stored procedure offrono anche un vantaggio in termini di sicurezza in quanto è possibile concedere diritti di esecuzione a una stored procedure ma l'utente non dovrà disporre delle autorizzazioni di lettura/scrittura sulle tabelle sottostanti. Questo è un buon primo passo contro SQL injection.
Le stored procedure hanno degli aspetti negativi, fondamentalmente la manutenzione associata all'operazione CRUD di base. Diciamo che per ogni tabella hai un Inserisci, Aggiorna, Elimina e almeno una selezione in base alla chiave primaria, ciò significa che ogni tabella avrà 4 procedure. Ora prendi un database di dimensioni decenti di 400 tabelle e hai 1600 procedure! E questo presuppone che tu non abbia duplicati che probabilmente avrai.
È qui che l'utilizzo di un ORM o di qualche altro metodo per generare automaticamente le operazioni CRUD di base ha un sacco di meriti.
