Yimp

Molto spesso, quando ci vengono affidati corsi di base di SQL per lavoratori neoassunti, ci viene chiesto di utilizzare MySql. In questo articolo vi spiego cinque motivi per cui MySql non è a mio parere il DBMS migliore per illustrare l’SQL a scopo didattico, in particolar modo a persone che si approcciano per la prima volta seriamente a tale linguaggio. Alcune di queste caratteristiche potrebbero essere viste anche come un “benefit” se osservate dal punto di vista di un programmatore esperto, ma didatticamente rappresentano per me un ostacolo nella strada per insegnare e imparare a scrivere query che restituiscano informazioni corrette, oltre a semplicemente terminare senza errori di esecuzione.   Gestione colonne non raggruppate Molto spesso, il primo concetto un po’ ostico da digerire per gli studenti all’interno di un corso introduttivo di Sql è il raggruppamento. La tentazione di aggiungere nella select, senza l’utilizzo di funzioni di aggregazioni, delle colonne che non sono presenti nel group by è molto forte all’inizio, nonostante le ripetute raccomandazioni. In questi casi, un bel messaggio di errore sarebbe gradito ed “educativo”. Invece su Mysql, una query come la seguente compila senza errori associando ad ogni regione di residenza un nome casuale tra quelli del gruppo. SELECT    RegioneResidenza,                    Nome,                    count(*) as NumeroClienti FROM       Clienti GROUP BY RegioneResidenza;   FULL JOIN non utilizzabile Un altro argomento fondamentale in un corso introduttivo sull’SQL sono le varie tipologie di JOIN. Per quanto un programmatore esperto possa raggiungere facilmente lo stesso obiettivo con del codice leggermente più complicato, dal punto di vista didattico la mancanza della FULL JOIN risulta frustante per gli insegnanti e per gli studenti, in quanto nel flusso della lezione è naturale chiedersi quale sintassi utilizzare per avere un comportamento pari “all’unione” dei costrutti LEFT JOIN e RIGHT JOIN.   Gestione JOIN senza ON Purtroppo l’esperienza in azienda mi ha mostrato come tutt’oggi molti sviluppatori utilizzino la sintassi deprecata “virgola nella From più condizioni nella where” per eseguire una JOIN tra più tabelle, scrivendo query come questa SELECT * FROM   Fatture, Clienti WHERE Fatture.IdCliente = Clienti.IdCliente; Tra i molteplici motivi per cui questa sintassi è sconsigliata (probabilmente ci dedicheremo un altro articolo), potrebbe esserci quello per cui l’inavvertita cancellazione delle condizioni nella where porterebbe a dei risultati abbondantemente errati, invece di un errore in fase di compilazione. Tuttavia ciò non si applica a MySql. Questa query infatti compila ed è equivalente ad una cross join. Provare per credere… SELECT  * FROM    Fatture INNER JOIN Clienti;   Gestione nuove colonne in tabelle già popolate Dopo le lezioni sull’interrogazione, si passa alle istruzioni DML. Reputo molto istruttivo dal punto di vista didattico far riflettere gli studenti sulla necessità di definire una nuova colonna con l’attributo NULL se la tabella è già popolata. Dopo la creazione, aggiorneremo tale colonna con un update e infine, se necessario, la modificheremo per darle l’attributo NOT NULL. Su MySQL invece possiamo tranquillamente aggiungere fin da subito una colonna con l’attributo NOT NULL. Verranno inseriti in automatico degli zeri se la colonna è di tipo numerico, o alternativamente delle stringhe vuote. Tale comportamento può essere anche comodo in fase di sviluppo per un programmatore esperto e consapevole, ma dal punto di vista didattico non è l’ideale per chi sta imparando.   Operazioni tra tipi differenti Una fetta importante degli errori runtime su codice Sql è legato ad errate conversioni in operazioni tra dati di tipo differente. Dal punto di vista didattico reputo fondamentale investire molto tempo sul concetto di tipo associato alle colonne, sottolineando come esso sia un elemento cardine nella definizione di tabella e di quante problematiche (anche legati alle performance) possa portare la scelta di tipi sbagliati. Usare MySql per fare le dimostrazioni non è proprio l’ideale visto che questa query compila e da 1. SELECT ‘a’+1;   Articoli correlati Scopri le differenze tra Sql Server e Oracle per lavorare correttamente su entrambi gli ambienti.

Riportiamo integralmente in questo articolo una delle nuove domande sul piano di esecuzione di una query che abbiamo aggiunto al corso-test su Udemy, spiegando in seguito la risposta. Lo studio del piano di esecuzione di una query è uno step imprescendibile per valutarne le perfomance e le possibilità di tuning. Creiamo una tabella Clienti con tre colonne CREATE TABLE Clienti (NumeroCliente int not null, Nome varchar(100) not null, Cognome varchar(100) not null); Popoliamola con un po’ di record INSERT INTO Clienti (NumeroCliente, Nome, Cognome) VALUES (1, ‘Francesco’, ‘Marino’), (2, ‘Francesco’, ‘Gialli’), (3, ‘Francesco’, ‘Verdi’), (4, ‘Carlo’, ‘Rossi’); Aggiungiamo una chiave primaria sulla colonna NumeroCliente e una struttura d’appoggio sulla colonne Nome . ALTER TABLE Clienti ADD PRIMARY KEY (NumeroCliente); CREATE NONCLUSTERED INDEX IndiceNome ON Clienti(nome); Consideriamo queste tre query con una struttura molto simile: SELECT Nome FROM Clienti GROUP BY Nome; SELECT Cognome FROM Clienti GROUP BY Cognome; SELECT NumeroCliente FROM Clienti GROUP BY NumeroCliente; Quante tra queste query sono risolte esclusivamente con una scansione del clustered index? In quali è presente un algoritmo di ordinamento? Esaminiamole una alla volta, in basso sono riportati i piani di esecuzione.   Prima query: SELECT Nome FROM Clienti GROUP BY Nome; Le informazioni necessarie per risolvere la query sono contenute tutte nell’indice non clustered costruito sulla colonna nome. In questa struttura d’appoggio i dati sono già ordinati, di conseguenza l’operazione di rimozione dei duplicati sarà immediata. Concludendo, il piano di esecuzione prevederà una semplice scansione ordinata dell’indice (Index Scan) e l’aggregazione dei record uguali (Stream Aggregate) dal costo trascurabile.   Seconda query: SELECT Cognome FROM Clienti GROUP BY Cognome; Sul campo Cognome non è presente nessuna struttura d’appoggio. Il piano d’esecuzione sarà dunque obbligato a scansionare l’intero clustered index. Per rendere più efficiente l’operazione di rimozione dei duplicati sarà inoltre necessario un oneroso ordinamento (78% del costo totale).   Terza query: SELECT NumeroCliente FROM Clienti GROUP BY NumeroCliente; Occorre osservare che non sono necessarie operazioni di rimozione dei duplicati. Sql Server è consapevole che la colonna NumeroCliente è chiave primaria, di conseguenza si limiterà a scansionare i dati. Tale scansione sarà fatta sull’indice non clustered (invece che sull’indice clustered), probabilmente a causa della sua dimensione ridotta rispetto alla struttura principale che contiene tutte le colonne.   Ricapitolando, nessuna delle tre query proposte effettua esclusivamente una scansione del clustered index, mentre una query prevede un operatore di ordinamento (la seconda). In basso il piano di esecuzione delle tre query. Articoli correlati Leggi perché secondo noi il database MySql non rappresenta la scelta migliore per introdurre il linguaggio SQL a studenti che si approcciano per la prima volta a questo linguaggio.