In questo articolo parleremo di quattro buone abitudini che uno sviluppatore SQL deve avere per scrivere del codice SQL leggibile, facile da manutenere, che minimizzi le possibilità di errori e orientato a pratiche DevOps.

Specificare la lista delle colonne dopo Insert Into

Quando utilizziamo la sintassi INSERT INTO per popolare una tabella con dei valori fissi o con l’output di una query, dovremmo sempre specificare l’elenco delle colonne da valorizzare.

Spesso potremmo cadere nella tentazione di non riportare questo elenco, soprattutto quando tutte le colonne sono interessate dalla INSERT. Mi capita spesso di leggere query scritte in questo modo

INSERT INTO Clienti
SELECT  CodiceFiscale, 
        Nome, 
        Cognome, 
        DataNascita
FROM    ClientiStaging;

o ancor peggio così

INSERT INTO Clienti
SELECT  *
FROM    ClientiStaging;

Scrivendo questo codice, stiamo confidando sul fatto che lo schema delle tabelle Clienti e ClientiStaging non cambi mai. Per quanto in questa casistica le query svolgerebbero correttamente il proprio lavoro, pensate ai rischi enormi nel caso in cui cambi l’ordine delle colonne di una delle due tabelle. Riscrivere la query in questo modo

INSERT INTO Clienti (
             CodiceFiscale, 
             Nome, 
             Cognome, 
             DataNascita)
SELECT  CodiceFiscale, 
        Nome, 
        Cognome, 
        DataNascita
FROM    ClientiStaging;

rende il codice più chiaro, sottolinea la corrispondenza tra le colonne della tabella Sorgente e quelle della tabella Target, ed è infine resiliente sia a modifiche dell’ordine delle colonne, sia all’aggiunta di colonne con vincolo NULL alla tabella Clienti.

Specificare tipo di join e di ordinamento

Quasi tutti i costrutti dell’SQL hanno delle opzioni che, se non valorizzate esplicitamente dallo sviluppatore, acquisiscono dei valori di default. In alcuni casi però ritengo che sia molto meglio spendere un secondo in più per specificare tale opzioni, in modo da migliorare la chiarezza e la comprensibilità, sottolineando il fatto che quel codice è nato da una particolare e ponderata decisione.

Ad esempio se all’interno di una query scriviamo la parola join tra due tabelle, sarà eseguita una inner join. Questa operazione, oltre a combinare le tabelle, può in alcune circostanze lavorare come un vero e proprio filtro sul perimetro di analisi. Specificare che si sta richiedendo una inner join rende sicuramente lo scrittore e il lettore del codice più consapevole di cosa sarà eseguito.

Un esempio simile è applicabile nella clausola Order BY, dove in assenza di specifiche verrà eseguito un ordinamento ascendente. Specificare questo comportamento tramite la parola ASC può risultare sicuramente più comprensibile.

Concludiamo la sezione ricordando che all’interno di una WHERE, in assenza di parentesi, il connettore AND ha la precedenza sull’OR, a prescindere dall’ordine di scrittura. Rendere chiaro il modo in cui sono applicati i filtri tramite le parentesi e un’opportuna formattazione, aiuterà sicuramente il codice a risultare più chiaro e leggibile.

Prendere in considerazione l’uso di CTE e tabelle temporanee

Con l’SQL possiamo trattare problemi di analisi molto complessi, riducendoli a una successione di sotto-problemi più semplici e integrando gli output delle singole query tramite CTE, subquery e tabelle temporanee. In questo articolo trovi un mio approfondimento sulle CTE.

Molti sviluppatori scrivono codice SQL di questo tipo utilizzando esclusivamente le SubQuery. In alcuni casi invece utilizzare le CTE potrebbe migliorare sicuramente la leggibilità del codice. Pensate ad esempio ai casi in cui troviamo un codice con due o più sotto-query annidate una dentro l’altro. Mettiamo a confronto le due strutture.

Al crescere del numero di query da annidare, la CTE diventa a mio parere una soluzione migliore.

Quando gli step intermedi restituiscono un numero ridotto di righe, può essere un’ottima idea valutare l’utilizzo di una tabella temporanea. Pensiamo ad esempio a tutti quei casi in cui l’output di una query è guidato da una group by su una colonna con pochi valori.

Formattare il codice SQL

Alcuni IDE di sviluppo famose come SQL Server Management Studio non hanno una funzione di indentazione automatica del codice. Diventa dunque compito dello sviluppatore formattare il codice SQL correttamente per renderlo chiaro al suo scopo.

Andare a capo dopo ognuna delle parole chiave SELECT – FROM – WHERE – GROUP BY – HAVING è un primo requisito indispensabile. Io preferisco andare a capo anche:

• nella select dopo ogni colonna
• nella from dopo ogni tabella e ogni condizione di join
• nella where dopo ogni filtro
• eventualmente anche dopo ogni parametro di una funzione se ciò può aiutare la comprensione

Ecco un esempio di codice SQL formattato.

Articoli correlati per sviluppatori SQL

• In questo articolo discutiamo su alcuni errori frequenti con il linguaggio SQL
• Qui vediamo come convertire righe in colonne con l’SQL
• Impariamo a utilizzare cross apply e outer apply