SQL
Schone code in SQL

Invoering

Opmaak en spelling van trefwoorden en namen

Tabel- / kolomnamen

Twee veel voorkomende manieren om tabel- / kolomnamen op te maken zijn CamelCase en snake_case :

SELECT FirstName, LastName
FROM Employees
WHERE Salary > 500;

SELECT first_name, last_name
FROM employees
WHERE salary > 500;

Namen moeten beschrijven wat er in hun object is opgeslagen. Dit houdt in dat kolomnamen meestal enkelvoud moeten zijn. Of tabelnamen enkelvoud of meervoud moeten gebruiken, is een veelbesproken vraag, maar in de praktijk is het gebruikelijk om meervoud aan tabelnamen te gebruiken.

Het toevoegen van voorvoegsels of achtervoegsels zoals tbl of col vermindert de leesbaarheid, dus vermijd ze. Ze worden echter soms gebruikt om conflicten met SQL-trefwoorden te voorkomen en worden vaak gebruikt met triggers en indexen (waarvan de namen meestal niet worden vermeld in query's).

trefwoorden

SQL-trefwoorden zijn niet hoofdlettergevoelig. Het is echter gebruikelijk om ze in hoofdletters te schrijven.

SELECTEER *

SELECT * retourneert alle kolommen in dezelfde volgorde als ze in de tabel zijn gedefinieerd.

Wanneer u SELECT * , kunnen de gegevens die door een query worden geretourneerd, veranderen wanneer de tabeldefinitie verandert. Dit verhoogt het risico dat verschillende versies van uw toepassing of uw database niet compatibel zijn met elkaar.

Bovendien kan het lezen van meer kolommen dan nodig is de hoeveelheid schijf- en netwerk-I / O verhogen.

U moet dus altijd expliciet de kolom (men) opgeven die u daadwerkelijk wilt ophalen:

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

(Bij het uitvoeren van interactieve zoekopdrachten zijn deze overwegingen niet van toepassing.)

SELECT * doet echter geen pijn in de subquery van een EXISTS-operator, omdat EXISTS de feitelijke gegevens toch negeert (het controleert alleen of er ten minste één rij is gevonden). Om dezelfde reden is het niet zinvol om een specifieke kolom (men) voor EXISTS te vermelden, dus SELECT * eigenlijk logischer:

-- 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');

inspringen

Er is geen algemeen aanvaarde norm. Waar iedereen het over eens is, is dat het niet goed is om alles in één regel samen te persen:

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;

Zet minimaal elke clausule in een nieuwe regel en splits regels als ze anders te lang zouden worden:

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;

Soms is alles na het SQL-trefwoord dat een clausule introduceert, ingesprongen in dezelfde kolom:

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;

(Dit kan ook worden gedaan terwijl de SQL-trefwoorden goed worden uitgelijnd.)

Een andere veel voorkomende stijl is om belangrijke zoekwoorden op hun eigen regels te plaatsen:

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;

Het verticaal uitlijnen van meerdere vergelijkbare uitdrukkingen verbetert de leesbaarheid:

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

Het gebruik van meerdere regels maakt het moeilijker om SQL-opdrachten in te sluiten in andere programmeertalen. Veel talen hebben echter een mechanisme voor tekenreeksen met meerdere regels, bijvoorbeeld @"..." in C #, """...""" in Python of R"(...)" in C ++.

Doet mee

Expliciete joins moeten altijd worden gebruikt; impliciete joins hebben verschillende problemen:

• De join-voorwaarde bevindt zich ergens in de WHERE-clausule, vermengd met andere filtervoorwaarden. Dit maakt het moeilijker om te zien welke tabellen zijn samengevoegd en hoe.

• Vanwege het bovenstaande is er een hoger risico op fouten en is de kans groter dat ze later worden gevonden.

• In standaard SQL zijn expliciete joins de enige manier om outer joins te gebruiken:

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

• Expliciete joins staan de USING-clausule toe:

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

  (Dit vereist dat beide tabellen dezelfde kolomnaam gebruiken.
  GEBRUIKEN verwijdert automatisch de dubbele kolom uit het resultaat, bijv. De join in deze query retourneert een enkele RecipeID kolom.)