Quando utilizzare 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 interoperativa. Questi vantaggi includono:

• Prestazione Le procedure sono in genere il modo più rapido per eseguire istruzioni SQL. Analogamente a un'esecuzione preparata, l'istruzione viene prima compilata e poi eseguita in due passaggi separati. A differenza dell'esecuzione preparata, le procedure vengono eseguite solo in fase di esecuzione. Vengono compilati in un momento diverso.

• Regole business Una regola di business è una regola sul modo in cui una società fa business. Ad esempio, solo un utente con il titolo Sales Person potrebbe essere autorizzato ad aggiungere nuovi ordini di vendita. L'inserimento di queste regole nelle procedure consente alle singole aziende di personalizzare le applicazioni verticali riscrivendo le procedure chiamate dall'applicazione senza dover modificare il codice dell'applicazione. Ad esempio, un'applicazione di immissione dell'ordine potrebbe chiamare la procedura InsertOrder con un numero fisso di parametri; esattamente come Viene implementato InsertOrder può variare da azienda a azienda.

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

• SQL specifico di DBMS Le procedure consentono alle applicazioni di sfruttare SQL specifico di DBMS e rimangono interoperabili. Ad esempio, una routine in un DBMS che supporta istruzioni control-of-flow in SQL potrebbe intercettare e recuperare dagli errori, mentre una routine in un SISTEMA DBMS che non supporta istruzioni control-of-flow potrebbe semplicemente restituire un errore.

• Le procedure sopravvivono alle transazioni In alcune origini dati, i piani di accesso per tutte le istruzioni preparate su una connessione vengono eliminati quando viene eseguito il commit o il rollback di una transazione. Inserendo 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 dipende dal DBMS.

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

Le procedure vengono in genere usate da applicazioni verticali e personalizzate. Queste applicazioni tendono a eseguire attività fisse, ed è possibile codificare in modo fisso le chiamate di procedura al loro interno. Ad esempio, un'applicazione di immissione dell'ordine potrebbe chiamare le procedure InsertOrder, DeleteOrder, UpdateOrder e GetOrders.

C'è poco motivo per chiamare le procedure da applicazioni generiche. Le procedure vengono in genere scritte per eseguire un'attività nel contesto di una determinata applicazione e pertanto non hanno alcun uso per applicazioni generiche. Ad esempio, un foglio di calcolo non ha alcun motivo per chiamare la routine InsertOrder appena menzionata. Inoltre, le applicazioni generiche non devono costruire procedure in fase di esecuzione nella speranza di fornire un'esecuzione più rapida delle istruzioni; non solo questo è probabilmente più lento rispetto all'esecuzione preparata o diretta, ma richiede anche istruzioni SQL specifiche di DBMS.

Un'eccezione a questo è costituito da ambienti di sviluppo di applicazioni, che spesso consentono ai programmatori di compilare istruzioni SQL che eseguono procedure e possono fornire ai programmatori un modo per testare le procedure. Tali ambienti chiamano SQLProcedures per elencare le procedure disponibili e SQLProcedureColumns per elencare i parametri di input, input/output e output, il valore restituito della routine e le colonne di tutti i set di risultati creati da una routine. 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. Ovvero, anche se le applicazioni possono chiamare le procedure in modo interoperabile, non possono crearle in modo interoperabile.