Di seguito viene riportato un elenco delle funzionalità aggiunte nelle ultime versioni del database server MySQL:
- Union dalla versione 4.0
- Subquery dalla versione 4.1
- Stored procedure dalla versione 5.0
- View dalla versione 5.0.1
- Cursori dalla versione 4.0
- Foreign key dalla versione 5.1 (dalla versione 3.23 sono disponibili per le tabelle InnoDB)
- Trigger dalla versione 5.0.2
- Full outer join dalla versione 5.1
- Costraint dalla versione 5.1
La funzionalità forse più interessante introdotta nelle ultime versioni del database sono le Stored Procedure. Una stored procedure può essere definita come un insieme di statement SQL che saranno mantenuti sul server.
Lo scopo è quello di evitare al client di riscrivere delle query complesse offrendo la possibilità invece di richiamare una procedura archiviata all'interno del database.
Un altro vantaggio è dato dall'incremento di prestazioni dovuto al fatto che il numero di informazioni che saranno scambiate tra client e server sarà molto minore, chiaramente il costo da pagare sarà un incremento del carico di lavoro sul sistema su cui gira il server MySQL dato che utilizzando queste procedure verrà demandato al server la maggior parte del lavoro mentre sarà alleggerito il carico sul client.
Utilizzare Stored Procedure permette di mantenere delle librerie di funzioni utilizzate comunemente all'interno del database stesso.
I casi in cui l'utilizzo delle procedure è fortemente consigliato sono principalmente quando si abbia a che fare con molti client, scritti magari in linguaggi differenti o basati su piattaforme diverse, i quali però necessitino tutti di effettuare le stesse operazioni sui database oppure quando la sicurezza e il logging delle operazioni sia la caratteristica principale del progetto: utilizzando stored procedure si introduce un ulteriore
livello di sicurezza e di log dato che le applicazioni e gli utenti non accederanno direttamente le tabelle ma potranno solamente eseguire particolari funzioni all'interno delle quali sarà possibile inserire dei meccanismi di log e di audit dedicati.
La sintassi utilizzata nello scrivere Stored Procedure in MySQL segue lo standard dettato da ANSI noto come SQL:2003.
Il team di MySQL AB sta ancora lavorando sull'implementazione delle stored procedure, si cercherà quindi di indicare le funzionalità già utilizzabili nella versione corrente e di segnalare quelle che saranno presenti in una prossima release.
La condizione fondamentale per l'utilizzo delle stored procedure è la presenza delle tabella proc nel database mysql, questa tabella viene creata durante l'installazione di questa versione del server, se si fosse effettuato invece un upgrade da una versione precedente verificare che esista.
Le routine in MySQL, sia che siano stored procedure oppure funzioni, sono create tramite l'istruzione CREATE PROCEDURE
oppure CREATE FUNCTION
.
Ciò che differenzia una procedura da una funzione è innanzitutto il fatto che nel primo caso l'invocazione deve avvenire utilizzando una
istruzione di CALL
mentre nel secondo caso è possibile utilizzare direttamente una funzione definita dall'utente
all'interno di una istruzione SQL così come si fa per le altre funzioni presenti in MySQL.
L'altra differenza tra le due modalità di gestione delle routine è che nel caso di procedure l'unico modo di ritornare dei valori è dato dall'utilizzo di variabili output mentre le funzioni possono ritornare direttamente un valore scalare.
In MySQL 5.0.1 le routine sono associate ad un particolare database, questo significa principalmente che rimuovendo (DROP) un database vengono cancellate anche tutte le Stored Procedure e Funzioni associate, che all'interno delle routine non è possible cambiare il database di riferimento tramite l'istruzione USE
e infine che è possibile richiamare routine appartenenti ad altri database indicandolo prima del nome della funzione/procedura. Si noti come questo comportamento è totalmente diverso da quello definito nella versione 5.0.0 nella quale le routine avevano valenza globale.
MySQL offre una estensione molto interessante all' SQL Standard: la possibilità di utilizzare statement di SELECT
direttamente all'interno di una stored procedure, in questo caso il record set risultante verrà inviato direttamente al client che sta eseguendo la procedura.
Le Views permettono di accedere ai record risultanti di una query su un insieme di tabelle come se questi fossero mantenuti in una singola tabella offrendo in questo modo la possibilità di limitare l'accesso ai soli campi definiti come appartenenti alla view.
La modalità per creare una view è del tipo
CREATE [OR REPLACE] [ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}] VIEW nome_della_view [(lista_di_campi)]
AS istruzione_di_select
[WITH [CASCADED | LOCAL] CHECK OPTION]
Dato che le tabelle e le view condividono lo stesso namespace non è possibile creare all'interno dello stesso database una tabella e una view con lo stesso nome. Inoltre così come avviene per le tabelle regolari anche in una view non è possibile specificare due colonne con lo stesso nome, per default vengono considerati i nomi delle colonne cosi come sono estratti dal costrutto di selezione, in alternativa è possibile indicare i nomi dei campi tramite il parametro opzionale lista_di_campi che dovrà contenere lo stesso esatto numero di campi estratti dalla query di creazione.
E' possibile, all'interno della query di creazione della view, riferirsi a tabelle di altri database così come utilizzare operatori, funzioni e costanti.
Mentre i vincoli legati alla creazione di una view sono: non è possibile utilizzare una subquery nella clausola della istruzione_di_select, non è possibile fare riferimento a tabelle temporanee e infine le tabelle e le view a cui ci si riferisce devono esistere almeno all'atto di creazione della view, successivamente è possibile droppare una tabella (o una view) anche se questa è stata utilizzata in una view.
L'opzione WITH CHECK OPTION
, implementata a partire dalla versione 5.0.2 indica che sarà possibile inserire o modificare i valori solamente dei record per cui la clausola WHERE nella istruzione_di_select è vera, CASCADED
(il default) e LOCAL
indicano se attuare il controllo su tutte le view sottostanti oppure solo localmente alla particolare view.
Un Trigger è un oggetto del database che, associato ad una tabella, si attiva al presentarsi di un particolare evento (azione intrapresa) sulla particolare tabella.
Un utilizzo classico è quello di loggare, tramite un trigger che inserisce record in una tabella preposta, le varie movimentazioni (insert, update, delete) dei record di una tabella molto critica per il sistema.
La creazione di un trigger introdotta a partire dalla versione MySQL 5.0.2, si basa sulla sintassi
CREATE TRIGGER nome_del_trigger BEFORE|AFTER INSERT|UPDATE|DELETE
ON tabella FOR EACH ROW istruzioni
Come si vede il trigger deve essere associato ad una tabella, questa deve essere una tabella "reale", non quindi una tabella temporanea o una view.
L'esecuzione del trigger può avvenire prima o dopo l'evento, questo viene indicato dalla scelta dell'opzione BEFORE
o AFTER
mentre l'evento scatenante può essere un operazione di INSERT
, di UPDATE
oppure di DELETE
. Si noti come non sia possibile attivare due distinti trigger sulla stessa azione e sullo stesso momento: ad esempio non possiamo avere due trigger BEFORE INSERT
sulla stessa tabella, possiamo però attivarne uno di tipo BEFORE INSERT
e uno di tipo AFTER INSERT
.
L'azione da intraprendere quando il trigger viene attivato è specificata dopo avere indicato FOR EACH ROW
, questa può essere un singolo statement oppure un blocco di istruzioni delimitato, al solito, da BEGIN ... END
.
Di interesse il fatto che all'interno della definizione di un trigger è possibile fare riferimento ai valori che un campo assume prima che sia modificato o cancellato: in questo caso si utilizza OLD.nome_campo
, oppure il valore che il campo assume dopo che è stata inserita una nuova riga oppure modificata una esistente: NEW.nome_campo
.