SQL
Pulisci codice in SQL

introduzione

Formattazione e ortografia di parole chiave e nomi

Nomi tabella / colonna

Due modi comuni di formattazione dei nomi di tabelle / colonne sono CamelCase e snake_case :

SELECT FirstName, LastName
FROM Employees
WHERE Salary > 500;

SELECT first_name, last_name
FROM employees
WHERE salary > 500;

I nomi dovrebbero descrivere ciò che è memorizzato nel loro oggetto. Ciò implica che i nomi delle colonne di solito dovrebbero essere singolari. Se i nomi dei tavoli debbano usare singolare o plurale è una domanda molto discussa , ma in pratica è più comune usare nomi di tabelle plurali.

L'aggiunta di prefissi o suffissi come tbl o col riduce la leggibilità, quindi evitali. Tuttavia, a volte vengono utilizzati per evitare conflitti con le parole chiave SQL e spesso utilizzati con trigger e indici (i cui nomi di solito non sono menzionati nelle query).

parole

Le parole chiave SQL non sono case sensitive. Tuttavia, è prassi comune scriverli in maiuscolo.

SELEZIONA

SELECT * restituisce tutte le colonne nello stesso ordine in cui sono definite nella tabella.

Quando si utilizza SELECT * , i dati restituiti da una query possono cambiare ogni volta che cambia la definizione della tabella. Ciò aumenta il rischio che diverse versioni della tua applicazione o del tuo database siano incompatibili tra loro.

Inoltre, la lettura di più colonne del necessario può aumentare la quantità di I / O del disco e della rete.

Pertanto, devi sempre specificare esplicitamente le colonne che vuoi effettivamente recuperare:

--SELECT *                                 don't
  SELECT ID, FName, LName, PhoneNumber  -- do
  FROM Emplopees;

(Quando si eseguono query interattive, queste considerazioni non si applicano).

Tuttavia, SELECT * non fa male nella sottoquery di un operatore EXISTS, perché EXISTS ignora comunque i dati effettivi (controlla solo se è stata trovata almeno una riga). Per lo stesso motivo, non è significativo elencare colonne specifiche per EXISTS, quindi SELECT * effettivamente più senso:

-- list departments where nobody was hired recently
SELECT ID,
       Name
FROM Departments
WHERE NOT EXISTS (SELECT *
                  FROM Employees
                  WHERE DepartmentID = Departments.ID
                    AND HireDate >= '2015-01-01');

Rientro

Non esiste uno standard ampiamente accettato. Ciò su cui tutti sono d'accordo è che spremere tutto in una singola riga è sbagliato:

SELECT d.Name, COUNT(*) AS Employees FROM Departments AS d JOIN Employees AS e ON d.ID = e.DepartmentID WHERE d.Name != 'HR' HAVING COUNT(*) > 10 ORDER BY COUNT(*) DESC;

Come minimo, inserire ogni clausola in una nuova riga e dividere le righe se diventeranno troppo lunghe altrimenti:

SELECT d.Name,
       COUNT(*) AS Employees
FROM Departments AS d
JOIN Employees AS e ON d.ID = e.DepartmentID
WHERE d.Name != 'HR'
HAVING COUNT(*) > 10
ORDER BY COUNT(*) DESC;

A volte, tutto dopo che la parola chiave SQL che introduce una clausola viene rientrata nella stessa colonna:

SELECT   d.Name,
         COUNT(*) AS Employees
FROM     Departments AS d
JOIN     Employees AS e ON d.ID = e.DepartmentID
WHERE    d.Name != 'HR'
HAVING   COUNT(*) > 10
ORDER BY COUNT(*) DESC;

(Questo può essere fatto anche allineando correttamente le parole chiave SQL).

Un altro stile comune consiste nel mettere le parole chiave importanti sulle proprie linee:

SELECT
    d.Name,
    COUNT(*) AS Employees
FROM
    Departments AS d
JOIN
    Employees AS e
    ON d.ID = e.DepartmentID
WHERE
    d.Name != 'HR'
HAVING
    COUNT(*) > 10
ORDER BY
    COUNT(*) DESC;

L'allineamento verticale di più espressioni simili migliora la leggibilità:

SELECT Model,
       EmployeeID
FROM Cars
WHERE CustomerID = 42
  AND Status     = 'READY';

L'uso di più linee rende più difficile incorporare comandi SQL in altri linguaggi di programmazione. Tuttavia, molte lingue hanno un meccanismo per stringhe multi-linea, ad es. @"..." in C #, """...""" in Python o R"(...)" in C ++.

Si unisce

Dovrebbero essere sempre utilizzati join espliciti; i join impliciti hanno diversi problemi:

• La condizione di join è da qualche parte nella clausola WHERE, mescolata con qualsiasi altra condizione di filtro. Ciò rende più difficile vedere quali tabelle sono unite e come.

• A causa di quanto sopra, c'è un rischio più elevato di errori, ed è più probabile che vengano trovati più tardi.

• In SQL standard, i join espliciti sono l'unico modo per utilizzare i join esterni :

  SELECT d.Name,
         e.Fname || e.LName AS EmpName
  FROM      Departments AS d
  LEFT JOIN Employees   AS e ON d.ID = e.DepartmentID;
  

• I join espliciti consentono di utilizzare la clausola USING:

  SELECT RecipeID,
         Recipes.Name,
         COUNT(*) AS NumberOfIngredients
  FROM      Recipes
  LEFT JOIN Ingredients USING (RecipeID);
  

  (Ciò richiede che entrambe le tabelle utilizzino lo stesso nome di colonna.
  USING rimuove automaticamente la colonna duplicata dal risultato, ad esempio, il join in questa query restituisce una singola colonna RecipeID .)