Torna all'elenco degli articoli Articoli
Tempo di lettura: 8 minuti

24 regole dello standard di formattazione SQL

La scrittura di query per un database richiede la conoscenza della sintassi SQL, ma non è l'unica cosa da sapere. Le migliori pratiche per scrivere codice SQL professionale richiedono buone capacità di formattazione. In questo articolo vi spiego perché è così importante e quali sono le regole di base da seguire.

Perché è utile formattare il codice SQL?

I programmatori SQL principianti spesso non prestano molta attenzione alla formattazione del codice. Se pensate che la formattazione sia qualcosa che si può tranquillamente ignorare, guardate il codice qui sotto:

SELECT id, FirstName, LASTNAME,c.nAme FROM people p left JOIN cities AS c on c.id=p.cityid;

Questa query SQL è stata scritta senza utilizzare alcuna regola di formattazione. Ora confrontatela con la query formattata qui sotto, che è lo stesso codice:

     SELECT p.PersonId,
            p.FirstName,
            p.LastName,
            c.Name
       FROM Person AS p 
  LEFT JOIN City AS c 
         ON p.CityId = c.CityId;

Vedete la differenza? Quale è più leggibile? Quale query è più facile da capire?

È ovvio che la prima query non è molto facile da leggere. A parte questo, è anche un problema apportare rapidamente modifiche a questo codice. Se si volesse confrontare questa query con un'altra simile, non sarebbe un compito facile. La seconda query è completamente diversa, anche se è esattamente lo stesso codice: è facile da leggere, sarebbe facile correggere il codice e sarebbe semplice confrontarlo con un altro codice ben formattato. Una corretta formattazione del codice SQL aiuta i programmatori a evitare errori.

Ok, ora avete capito perché formattare il codice SQL potrebbe essere una buona idea. Ora è il momento di imparare a farlo.

Come formattare il codice SQL

Esistono diversi modi di affrontare la formattazione del codice. Alcuni programmatori SQL hanno stili e preferenze individuali per la formattazione delle query SQL. Hanno esperienza nella programmazione e seguono le regole che gli sono più congeniali. Questo non è un male se si lavora solo sui propri progetti, ma se si lavora insieme ad altri colleghi? Lavorare in un team sarebbe problematico se ogni programmatore scrivesse il codice utilizzando il proprio stile individuale. Il codice rappresenterebbe un miscuglio di regole in un unico progetto. La soluzione sarebbe quella di definire una serie di principi per l'intero team. Ma cosa succede se il codice deve essere letto o corretto da persone esterne all'azienda? La soluzione migliore, in generale, è seguire lo standard di formattazione SQL. Non esiste un documento ufficiale al riguardo, ma esistono alcuni standard e buone pratiche generalmente condivisi e scritti da esperti di SQL. Inoltre, esistono molti strumenti che aiutano a formattare il codice SQL e che si basano su questo standard. In questa guida discutiamo le regole più comuni e diffuse che si basano su questo standard.

Denominazione degli oggetti

Per prima cosa, discutiamo le regole generali di denominazione degli oggetti del database. Queste sono le regole più comuni:

  • Evitare il nome di una tabella/colonna al plurale. È meglio usare employee invece di employees.
  • Se il nome della tabella o della colonna deve essere composto da più di una parola, utilizzare un trattino basso per collegarle, ad esempio employee_city. Alcuni professionisti preferiscono invece utilizzare il cosiddetto stile CamelCase, ad esempio EmployeeCity. Lo stile preferito è diverso per i vari sistemi di database relazionali.
  • Verificare che il nome non sia già utilizzato come parola chiave in SQL.
  • Se il nome è uguale a una parola chiave SQL, racchiudere il nome tra virgolette.
  • Il nome di un oggetto in un database per una tabella o una colonna deve essere unico e non troppo lungo. Evitare i caratteri speciali nel nome, come $, &, * , ecc. (usare solo lettere, numeri e trattini bassi).
  • Utilizzare un trattino basso nel nome solo se necessario.
  • Non iniziare il nome con un trattino basso.
  • Utilizzare i commenti solo se necessario.
  • Evitate le abbreviazioni, ma se le usate, assicuratevi che siano comprensibili.
  • Evitare di dare lo stesso nome a una tabella e a una colonna.
  • Usare le stesse regole di denominazione per gli alias di colonne o tabelle.
  • Includere la parola chiave AS per la creazione di alias, perché rende il codice più leggibile.
  • Per la colonna della chiave primaria evitare il nome id. Una buona idea è quella di combinare id con il nome di una tabella, ad esempio: id_employee.

Allineamento

La maggior parte degli esperti consiglia di scrivere prima le parole chiave su una nuova riga a sinistra e poi il resto del codice a destra, in questo modo:

SELECT p.PersonId,
       p.FirstName,
       p.LastName,
       c.Name
  FROM Person AS p 
  JOIN City AS c 
    ON p.CityId = c.CityId;

Indentazione

L'uso liberale delle newline può aiutare molto la leggibilità di una query SQL. È buona norma utilizzare una nuova riga per ogni query separata e una nuova riga per ogni colonna separata dopo una virgola. Allo stesso modo, è buona norma usare gli spazi per circondare l'operatore equals, usare gli spazi prima o dopo gli apostrofi e usare uno spazio dopo la virgola.

Le sezioni seguenti presentano ulteriori dettagli sulle buone pratiche di indentazione nei diversi tipi di query SQL.

Commenti

Evitate di scrivere troppi commenti nel codice. Naturalmente, ci sono casi in cui i commenti sono necessari, ma di solito è meglio usare commenti a più righe, indicati dai caratteri /* di apertura e */ di chiusura. Si consiglia di scrivere questo tipo di commento all'inizio di una nuova riga, invece di iniziare una riga con il codice che viene eseguito. Il commento deve essere scritto sopra la riga di codice SQL corrispondente, utilizzando la stessa indentazione. Ad esempio:

SELECT p.PersonId,
       p.FirstName,
       p.LastName,
       /* Name column is the name of the city: */
       p.Name,
  FROM Person AS p 
 WHERE p.Name = 'New York';

Nel codice SQL è anche possibile aggiungere commenti di una riga. Questo tipo di commento è indicato da un doppio trattino (--) all'inizio del testo del commento. Tutto il testo dopo questi caratteri viene trattato come un commento.

SELECT -- we have to delete this column p.PersonId,
       p.FirstName,
       p.LastName,
       p.Name
  FROM Person AS p;

Query SELECT

In questo tipo di query SELECT è la prima parola del comando. Se ci sono molte colonne dopo SELECT, è meglio separarle mettendo ciascuna di esse su una riga separata. Ogni nuova riga deve essere rientrata. Assicuratevi di mettere le virgole alla fine della riga e non all'inizio.

SELECT p.PersonId,
       p.FirstName,  
       p.LastName,
       c.Name
  FROM Person AS p;

Per le parole chiave FROM, WHERE, ORDER BY, GROUP BY e HAVING, scrivete ciascuna su una nuova riga senza rientri.

SELECT p.PersonId,
       p.FirstName,
       p.LastName,
       p.Name,
  FROM Person AS p 
 WHERE p.Name = 'New York';

Se l'istruzione WHERE contiene più di una condizione, separare ogni condizione con una nuova riga rientrata e utilizzare una nuova riga rientrata con gli operatori condizionali AND o OR all'interno dell'istruzione WHERE.

SELECT p.PersonId,
       p.FirstName,
       p.LastName,
       p.Name
  FROM Person AS p 
 WHERE p.Name = 'New York' 
    OR p.Name = 'Chicago';

Dichiarazioni JOIN

Se si uniscono tabelle, utilizzare nuove righe per gli operatori INNER JOIN, LEFT JOIN, ecc. Per l'operatore ON, scrivere una nuova riga rientrata all'interno dell'istruzione JOIN. Se invece c'è più di una condizione, utilizzare una nuova riga rientrata prima dell'operatore condizionale AND o OR.

SELECT p.PersonId,
       p.FirstName,
       p.LastName,
       c.Name
  FROM Person AS p 
  JOIN City AS c 
    ON p.CityId = c.CityId;

Una query SQL lunga e annidata

Le query lunghe a volte contengono sottoquery. In questo caso, le sottoquery devono essere inserite in una nuova riga rientrata.

Per la struttura CASE, ogni WHEN e END deve essere posta su una nuova riga.

SELECT p.PersonId,
       p.FirstName,
       p.LastName,
       CASE 
         WHEN p.Age < 18 THEN 'below 18'
         WHEN p.Age >= 18 THEN '18 or more'
       END AS Age
  FROM Person AS p;

Altri tipi di query SQL

Esistono regole simili per le query che modificano, inseriscono o eliminano dati.

Usare il rientro per VALUES nelle query di inserimento:

INSERT INTO Car(id_car, name, year) VALUES
  (1, 'Audi', 2010) ; 

Nel caso in cui si inseriscano più righe in una query, scrivere ogni riga come una nuova riga con rientro:

INSERT INTO Car(id_car, name, year) VALUES
  (1, 'Audi', 2010) ,
  (2, 'Skoda', 2015) ; 

In modo simile, in una query UPDATE utilizzare SET e WHERE come in un'istruzione SELECT, con una nuova riga senza rientro:

UPDATE Car
SET year = 2012
WHERE Name = 'Audi';

o in una query DELETE:

DELETE FROM Car
WHERE Name = 'Audi'; 

Come una cattiva formattazione del codice SQL porta a dei problemi

Un esempio di come una cattiva formattazione porti a dei problemi si può vedere nella query qui sotto, in cui le virgole sono poste all'inizio di ogni riga:

SELECT /* we have to delete this column */ p.PersonId
     , p.FirstName
     , p.LastName
     , p.Name
  FROM Person AS p 
 WHERE p.Name = 'New York';

All'inizio potrebbe avere senso, ma se si commenta la prima colonna per rimuoverla, la query restituisce un errore.

Un altro errore può verificarsi se non si usa l'indentazione e le nuove righe. Per esempio:

Select person.id_person, person.name, person.age, person.description, person.city from person  where person.age>20 and person.city = ( select name from city where id_city>20)

In questo codice mal formattato sarebbe molto facile cancellare per errore la clausola WHERE nella sottoquery quando si intendeva cancellare la clausola WHERE nella query principale.

Molti problemi saranno facilmente individuabili se la query è formattata correttamente, soprattutto in una query lunga con centinaia di righe di codice.

Sintesi

Ignorare lo standard di formattazione SQL può causare problemi significativi quando si collabora con altri programmatori. Una formattazione corretta facilita la lettura del codice SQL e aiuta a prevenire gli errori quando si apportano modifiche al codice. In questo articolo ho presentato alcune delle regole raccomandate dagli esperti che aiutano a scrivere codice più chiaro. Scrivere un bel codice SQL è una buona abitudine lavorativa apprezzata dai datori di lavoro. Il vostro codice indica il vostro livello di professionalità e dimostra che avete un approccio moderno e serio al lavoro. Raccogliete la sfida e diventate programmatori più professionali!