Formater SQL

Przed i po

Przed:

SELECT u.id,u.name,COUNT(o.id) AS orders FROM users u LEFT JOIN orders o ON o.user_id=u.id WHERE u.created_at>='2024-01-01' GROUP BY u.id,u.name HAVING COUNT(o.id)>5 ORDER BY orders DESC LIMIT 50;

Po (przecinek na początku, słowa kluczowe wielkimi literami, wcięcie 2 spacje):

SELECT
    u.id
  , u.name
  , COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o
  ON o.user_id = u.id
WHERE u.created_at >= '2024-01-01'
GROUP BY u.id, u.name
HAVING COUNT(o.id) > 5
ORDER BY orders DESC
LIMIT 50;

Wybory stylu, które mają znaczenie

• Wielkie vs małe litery słów kluczowych. WIELKIE litery są tradycyjne i łatwe do skanowania. Małe litery wyglądają czyściej w nowoczesnych edytorach z podświetlaniem składni.
• Przecinki na początku vs na końcu. Na początku ( , col) ułatwia zakomentowanie pojedynczej kolumny. Na końcu (col,) czyta się naturalniej w tekście.
• Rozmieszczenie przecinków w GROUP BY. Często po jednym na linię dla długich klauzul, w jednej linii dla krótkich.
• Wcięcie JOIN. ON w kolejnej linii (wcięcie wiszące) vs w tej samej linii. Długie warunki zyskują na wcięciu wiszącym.
• Podzapytania. Wcinaj całe podzapytanie, nie tylko otwierający nawias.

Pułapki specyficzne dla dialektu

• Apostrofy odwrotne MySQL vs podwójne cudzysłowy PostgreSQL dla identyfikatorów.
• CTE z WITH, MS SQL wymaga ; przed WITH; formater to obsługuje.
• Funkcje okienkowe, długie klauzule OVER (...) zyskują na zawijanych w linie PARTITION BY i ORDER BY.
• BigQuery ma ARRAY_AGG, STRUCT i przyrostki tabel (*_yyyymmdd), których tokenizer nie może rozbić.
• Oracle ma składnię złączeń zewnętrznych (+), formater ją zachowuje, ale oznacza jako przestarzałą.

Czego formater nie robi

• Naprawianie błędów, niepoprawny JOIN pozostaje niepoprawny.
• Rozwijanie SELECT *, listy kolumn nie są wnioskowane ze schematu.
• Optymalizacja zapytań, tylko układ, nie plany wykonania.
• Przepisywanie podzapytań na CTE, to inna sprawa.