Quando usare le procedure

L'uso di procedure offre numerosi vantaggi, in base al fatto che l'uso di procedure sposta le istruzioni SQL dall'applicazione all'origine dati. Ciò che rimane nell'applicazione è una chiamata di procedura interoperabile. Questi vantaggi includono:

• Prestazioni Le procedure sono di solito il modo più veloce per eseguire le istruzioni SQL. Come l'esecuzione preparata, l'istruzione viene compilata ed eseguita in due fasi separate. A differenza dell'esecuzione preparata, le procedure vengono eseguite solo in fase di esecuzione. In questo caso vengono compilate in un momento diverso.

• Regole di business Una regola di business è una regola sul modo in cui una società fa business. Ad esempio, solo chi ha il titolo di addetto alle vendite può aggiungere nuovi ordini di vendita. L'inserimento di queste regole nelle procedure permette alle singole società di personalizzare le applicazioni verticali riscrivendo le procedure richiamate dall'applicazione senza dover modificare il codice dell'applicazione. Ad esempio, un'applicazione per l'inserimento di ordini potrebbe chiamare la procedura InsertOrder con un numero fisso di parametri; le modalità esatte di implementazione di InsertOrder possono variare da società a società.

• Sostituibilità Strettamente legato all'inserimento delle regole di business nelle procedure sta nel fatto che le procedure possono essere sostituite senza ricompilare l'applicazione. Se una regola di business cambia dopo che una società ha acquistato e installato un'applicazione, può cambiare la procedura che contiene tale regola. Dal punto di vista dell'applicazione, nulla è cambiato; chiama comunque una particolare procedura per eseguire una determinata attività.

• SQL specifico del DBMS Le procedure forniscono alle applicazioni un modo per sfruttare l'SQL specifico del DBMS e rimanere comunque interoperabili. Ad esempio, una procedura su un DBMS che supporta le istruzioni di controllo del flusso in SQL potrebbe intrappolare e recuperare gli errori, mentre una procedura su un DBMS che non supporta le istruzioni di controllo del flusso potrebbe semplicemente restituire un errore.

• Le procedure sopravvivono alle transazioni Su alcune fonti di dati, i piani di accesso per tutte le istruzioni preparate su una connessione vengono cancellati quando viene eseguito il commit o il rollback di una transazione. Inserendo le istruzioni SQL nelle procedure, archiviate in modo permanente nell'origine dati, le istruzioni sopravvivono alla transazione. Il fatto che le procedure sopravvivano in uno stato preparato, parzialmente preparato o non preparato è specifico del DBMS.

• Sviluppo separato Le procedure possono essere sviluppate separatamente dal resto dell'applicazione. Nelle grandi società, questo potrebbe essere un modo per sfruttare ulteriormente le competenze di programmatori altamente specializzati. In altre parole, i programmatori di applicazioni possono scrivere il codice dell'interfaccia utente e i programmatori di database possono scrivere le procedure.

Le procedure vengono in genere usate da applicazioni verticali e personalizzate. Queste applicazioni tendono a eseguire task fissi ed è possibile eseguire chiamate di routine hardcoded in essi. Ad esempio, un'applicazione di registrazione ordine potrebbe chiamare le procedure InsertOrder, DeleteOrder, UpdateOrder e GetOrders

Ci sono pochi motivi per chiamare le procedure da applicazioni generiche. Le procedure sono solitamente scritte per eseguire un task nel contesto di una particolare applicazione e quindi non sono utili per applicazioni generiche. Ad esempio, un foglio di calcolo non ha alcun motivo per chiamare la procedura InsertOrder appena menzionata. Inoltre, le applicazioni generiche non dovrebbero costruire procedure in fase di esecuzione nella speranza di ottenere un'esecuzione più rapida delle istruzioni; non solo è probabile che questa procedura sia più lenta dell'esecuzione preparata o diretta, ma richiede anche istruzioni SQL specifiche per il DBMS.

Un'eccezione è rappresentata dagli ambienti di sviluppo delle applicazioni, che spesso offrono ai programmatori un modo per costruire istruzioni SQL che eseguono le procedure e possono fornire ai programmatori un modo per testare le procedure. Questi ambienti chiamano SQLProcedures per elencare le procedure disponibili e SQLProcedureColumns per elencare i parametri di input, input/output e output, il valore di ritorno della procedura e le colonne degli eventuali set di risultati creati da una procedura. Tuttavia, tali procedure devono essere sviluppate in anticipo su ogni origine dati; in questo modo sono necessarie istruzioni SQL specifiche di DBMS.

Esistono tre svantaggi principali per l'uso delle procedure. Il primo consiste nel fatto che le procedure devono essere scritte e compilate per ogni DBMS con cui deve essere eseguita l'applicazione. Anche se questo non è un problema per le applicazioni personalizzate, può aumentare significativamente il tempo di sviluppo e manutenzione per le applicazioni verticali progettate per l'esecuzione con diversi DBMS.

Il secondo svantaggio è che molti DBMS non supportano le procedure. Anche in questo caso, è molto probabile che questo sia un problema per le applicazioni verticali progettate per l'esecuzione con diversi DBMS. Per determinare se le procedure sono supportate, un'applicazione chiama SQLGetInfo con l'opzione SQL_PROCEDURES.

Il terzo svantaggio, particolarmente applicabile agli ambienti di sviluppo di applicazioni, è che ODBC non definisce una grammatica standard per la creazione di procedure. In altre parole, sebbene le applicazioni possano chiamare le procedure in modo interoperabile, non possono crearle in modo interoperabile.