Przewodnik po stylu SQL: najlepsze praktyki formatowania

Przewodnik po stylu SQL to zbiór konwencji, dzięki którym zapytania są czytelne, a różnice w diffach zespołu pozostają spójne. Samego SQL to nie obchodzi: słowa kluczowe są niewrażliwe na wielkość liter, a białe znaki są ignorowane, więc SELECT, select i SeLeCt działają tak samo, a jednowierszowiec o długości 200 znaków zwraca dokładnie te same wiersze co to samo zapytanie rozłożone na dwadzieścia wciętych linii. Styl dotyczy zatem wyłącznie ludzi, którzy będą czytać zapytanie później.

Jeśli po prostu potrzebujesz teraz czystego zapytania, wklej je do formatera SQL, wybierz dialekt i skopiuj wynik. Ale to zrozumienie reguł stojących za tym wynikiem pozwala ustalić zespołowy standard, zamiast spierać się o niego przy każdym pull requeście. Ten przewodnik omawia decyzje, które mają znaczenie: wielkość liter słów kluczowych, wcięcia i łamanie wierszy, nazewnictwo, osobliwości poszczególnych dialektów oraz to, jak zautomatyzować całość.

Ponieważ SQL ignoruje białe znaki i wielkość liter, żadna z tych reguł nie jest egzekwowana przez bazę danych — istnieją po to, by służyć ludziom, którzy czytają i utrzymują zapytanie. Stąd dwie konsekwencje. Rzadko istnieje jedna „poprawna” odpowiedź; większość tych decyzji polega na wybraniu rozsądnej konwencji i stosowaniu jej wszędzie, a ten przewodnik wskazuje, gdzie leżą prawdziwe kompromisy. A ponieważ reguły są konwencjami, a nie wymogami, dają wartość tylko wtedy, gdy stosuje się je konsekwentnie: zdecyduj raz, a potem pozwól narzędziu to egzekwować.

Dlaczego formatowanie SQL ma znaczenie

Najjaśniejszy argument za formatowaniem ujawnia się podczas code review. ORM albo krok kompilacji często emituje zapytania jako jedną nieprzerwaną linię:

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.active=true group by u.id,u.name order by orders desc

Nikt nie jest w stanie tego zrecenzować. Po przeformatowaniu struktura staje się oczywista, a diff można czytać linia po linii:

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.active = true
GROUP BY u.id, u.name
ORDER BY orders DESC;

Debugowanie zyskuje tak samo. Gdy skopiujesz jednowierszowe zapytanie z logu wolnych zapytań, a ma ono trzy złączenia i splątany WHERE, sformatowanie go najpierw zamienia „gdzie jest błąd” w trzydziestosekundowy przegląd. Wadliwy predykat jest w osobnej linii, złączenia są ułożone jedno pod drugim, a przypadkowy iloczyn kartezjański albo zapomniany filtr nagle staje się widoczny, zamiast być zagrzebany w ścianie tekstu. Ta sama sztuczka pomaga, gdy czytasz SQL wygenerowany przez jakiś inny system — konstruktory zapytań i narzędzia raportowe często emitują wynik poprawny, lecz nieczytelny.

Spójność to cichszy zysk, a z czasem najcenniejszy. Gdy wszyscy formatują tak samo, diffy pokazują tylko to, co faktycznie się zmieniło — nową kolumnę, zmodyfikowany filtr — zamiast szumu z preferencji jednej osoby co do odstępów ścierających się z preferencjami innej. Uwaga recenzenta jest skończona; wydawanie jej na przeformatowane białe znaki to marnotrawstwo. Spójne formatowanie ułatwia też wdrażanie nowych osób: świeżo zatrudniony czyta zapytania, które wszystkie wyglądają podobnie, uczy się zespołowego kształtu raz i stosuje go wszędzie. Nic z tego nie wymaga, by ktokolwiek formatował ręcznie, co jest motywem ostatniej sekcji — ty decydujesz o regułach, a narzędzie je stosuje.

Jeden niezmiennik leży u podstaw tego wszystkiego i warto powiedzieć go wprost, bo powtarza się w całym przewodniku: formatowanie zmienia tylko białe znaki, łamanie wierszy, wielkość liter słów kluczowych i komentarze. Nigdy nie zmienia logiki zapytania ani jego wyników. Sformatowane zapytanie to to samo zapytanie. Dlatego możesz bezpiecznie przepuścić powyższą bałaganiarską wersję przez formater SQL, nie martwiąc się o to, co zwróci.

Wielkość liter słów kluczowych — UPPERCASE vs lowercase

Najstarszy spór w każdym przewodniku po stylu SQL dotyczy tego, czy słowa zarezerwowane powinny być pisane UPPERCASE czy lowercase. Oba warianty są poprawne, bo SQL jest niewrażliwy na wielkość liter w słowach kluczowych. Spór toczy się o czytelność i warto zrozumieć obie strony, zanim dokonasz wyboru.

Argument za wielkimi literami w słowach kluczowych

Tradycyjny argument to kontrast wizualny. Pisanie SELECT, FROM, WHERE, JOIN i GROUP BY wielkimi literami sprawia, że słowa kluczowe wyróżniają się na tle pisanych małymi literami nazw tabel i kolumn, więc możesz przeskanować kształt zapytania — jego klauzule, jego strukturę — bez polegania na edytorze, który je pokoloruje.

Liczy się to dlatego, że SQL przewija się przez mnóstwo miejsc, które nie mają podświetlania składni: pliki logów, wątki e-mailowe, opisy pull requestów, czysty tekstowy diff, wiadomość na Slacku, pulpit monitoringu, ślad stosu. We wszystkich tych miejscach wielkie litery słów kluczowych są jedyną rzeczą utrzymującą czytelność struktury — zdejmij podświetlanie, a select id from users where active zamienia się w zupę małych liter, podczas gdy SELECT id FROM users WHERE active wciąż czyta się jako zapytanie na pierwszy rzut oka. To konwencja, którą znajdziesz w większości starszych przewodników po stylu, w dokumentacji baz danych i niemal w każdym podręczniku SQL, co jest też powodem, dla którego wielu programistów uważa wielkie litery w słowach kluczowych za bardziej znajome, nawet gdy ich edytor i tak by je pokolorował.

Argument za małymi literami w słowach kluczowych

Współczesny kontrargument głosi, że podświetlanie składni rozwiązało problem kontrastu. Każdy edytor i IDE koloruje słowa kluczowe wyraźnie, więc pisanie ich wielkimi literami jest zbędne — a dla niektórych czytelników wszystko zapisane wielkimi literami brzmi jak krzyk. Pisanie małymi literami jest też nieco szybsze, bo nie trzeba sięgać po shift przy każdym słowie kluczowym.

Styl z małymi literami ma realny rozpęd w świecie inżynierii analitycznej. Społeczność dbt i kilka szeroko cytowanych zespołowych przewodników po stylu domyślnie używa małych liter w słowach kluczowych, kierując się logiką, że to podświetlanie niesie wizualny ciężar, a małe litery sprawiają, że zapytanie czyta się spokojniej. Jest też subtelniejszy argument na ich korzyść: małe litery słów kluczowych są na tym samym poziomie wizualnym co twoje nazwy tabel i kolumn w snake_case, więc całe zapytanie czyta się jako jeden spójny fragment tekstu, a nie jako dwa rejestry — krzyczące słowa kluczowe i ciche identyfikatory — rywalizujące o uwagę. To, czy jest to zaleta, czy wada, zespoły rozstrzygają różnie — co prowadzi nas do jedynego werdyktu, który naprawdę się broni.

Werdykt — spójność bije sam wybór

Sedno jest takie: który wariant wybierzesz, jest znacznie mniej istotne niż to, że wybierzesz jeden i będziesz go egzekwować. Baza kodu, w której połowa zapytań krzyczy SELECT, a druga połowa szepcze select, to najgorszy wynik, bo sama niespójność staje się szumem. Mieszana wielkość liter w jednym zapytaniu jest jeszcze gorsza.

Powód, dla którego spójność wygrywa, jest mechaniczny, a nie estetyczny. Niespójna wielkość liter sprawia, że diffy kłamią: recenzent widzi „zmianę” w linii, która w rzeczywistości jest tylko czyimś przeformatowaniem słowa kluczowego, a właściwa zmiana ukrywa się w szumie. Grep i wyszukiwanie też stają się mniej niezawodne, gdy to samo słowo kluczowe pojawia się w trzech wariantach wielkości liter. Jeden egzekwowany styl usuwa cały ten narzut kosztem jednej decyzji. Zdecydujcie więc jako zespół, zapiszcie to i pozwólcie narzędziu egzekwować zamiast polegać na dyscyplinie. Formater SQL ma kontrolkę Keywords z trzema opcjami — UPPERCASE, lowercase i Preserve — więc możesz znormalizować cały stos historycznych zapytań do jednego stylu jednym kliknięciem. To samo zapytanie wyrenderowane na oba sposoby:

-- UPPERCASE
SELECT id, email FROM users WHERE active = true ORDER BY created_at DESC;

-- lowercase
select id, email from users where active = true order by created_at desc;

Wybierz ten, który preferuje twój zespół. Chodzi o to, by wszystkie twoje zapytania do niego pasowały.

Wcięcia i łamanie wierszy

Wielkość liter decyduje o tym, jak wyglądają słowa kluczowe. Wcięcia i łamanie wierszy decydują o tym, jak logika zapytania mapuje się na stronę, i to tutaj kryje się większość czytelności.

Styl „rzeki” vs styl blokowy

Dobrze znany sqlstyle.guide autorstwa Simona Holywella spopularyzował styl „rzeki”, w którym słowa kluczowe są wyrównane do prawej, tak że pionowy kanał białych znaków biegnie środkiem zapytania:

SELECT id,
       email,
       created_at
  FROM users
 WHERE active = true
 ORDER BY created_at DESC;

Urok polega na tym, że SELECT, FROM i WHERE ustawiają się wzdłuż swojej prawej krawędzi, a lista kolumn siedzi schludnie na prawo od rzeki. Wady są jednak praktyczne. Wyrównanie zależy od długości twojego najdłuższego słowa kluczowego, więc dodanie LEFT JOIN może zmusić cię do ponownego wcięcia wszystkiego; jest to uciążliwe w utrzymaniu ręcznym; i produkuje hałaśliwe diffy, bo zmiana długości jednego słowa kluczowego przesuwa białe znaki w sąsiednich liniach.

Styl blokowy (czyli wyrównany do lewej) zaczyna każdą główną klauzulę przy lewym marginesie, w osobnej linii, i wcina zawartość klauzuli:

SELECT
  id,
  email,
  created_at
FROM users
WHERE active = true
ORDER BY created_at DESC;

To główny domyślny styl i ten, który produkuje większość narzędzi, właśnie dlatego, że jest stabilny: dodanie klauzuli nigdy nie przelewa linii powyżej, więc diffy pozostają małe, a układ przetrwa automatyczne formatowanie. Styl rzeki optymalizuje pod to, jak gotowe zapytanie wygląda w izolacji; styl blokowy optymalizuje pod to, jak zapytania zmieniają się w czasie i jak recenzuje się je w systemie kontroli wersji. Dla wszystkiego, co żyje w repozytorium i bywa edytowane, styl blokowy jest bezpieczniejszym wyborem, i to jego zakłada reszta tego przewodnika.

Ile spacji — 2 vs 4 vs taby

Gdy już wcinasz, musisz zdecydować, jak głęboko. Trzy popularne odpowiedzi mają każda swoje uzasadnienie:

• 2 spacje — najczęstsze ustawienie domyślne. Utrzymuje diffy zwarte, a zagnieżdżone zapytania powstrzymuje przed maszerowaniem poza prawą krawędź ekranu.
• 4 spacje — daje każdemu poziomowi zagnieżdżenia więcej separacji wizualnej, co pomaga w zapytaniach z głębokimi podzapytaniami lub wieloma poziomami CTE.
• Taby — pozwalają każdemu programiście wybrać własną szerokość wyświetlania bez zmiany pliku.

Nie ma tu uniwersalnie poprawnej odpowiedzi, i właśnie dlatego formater SQL udostępnia kontrolkę Indent ze wszystkimi trzema (2 spaces, 4 spaces, Tab). Wybierz jedną i stosuj ją wszędzie.

Gdzie łamać wiersze

Szerokość wcięcia to łatwa część. Decyzją o większym wpływie jest to, gdzie wstawić łamania wierszy:

• Kolumny SELECT — jedna kolumna na linię dla wszystkiego nietrywialnego, tak by dodanie lub usunięcie kolumny dotykało dokładnie jednej linii w diffie. Bardzo krótkie zapytania mogą zostać w jednej linii.
• FROM i JOIN — zaczynaj każde złączenie w osobnej linii, z warunkiem ON albo na końcu, albo wciętym pod spodem. Dzięki temu graf złączeń pozostaje czytelny.
• WHERE — umieść każde AND / OR w osobnej linii, by logika boolowska czytała się z góry na dół. Dla mieszanych warunków AND/OR ujmij w nawiasy i wcinaj grupy, aby pierwszeństwo było jawne, a nie czymś, co czytelnik musi rozpracować.

To są wskazówki, nie prawa. Trywialne SELECT id FROM users WHERE id = 1 nie potrzebuje pięciu linii, a wymuszanie ich szkodzi czytelności, zamiast pomagać. Ocena sytuacji jest z grubsza taka: łam, gdy zapytanie ma więcej niż jedną lub dwie kolumny, więcej niż jedną tabelę albo więcej niż jeden warunek. Poniżej tego progu jedna linia jest czytelniejsza; powyżej niego łam agresywnie. Dobry formater koduje rozsądny próg za ciebie, ale warto rozumieć zasadę, by wynik nigdy cię nie zaskoczył.

Zastosowane do bałaganiarskiego jednowierszowca z wcześniej, te reguły dają układ, w którym każda klauzula i każde złączenie jest widoczne na pierwszy rzut oka:

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.active = true
GROUP BY u.id, u.name
ORDER BY orders DESC;

Przecinki na początku vs na końcu

Mniejsza, ale uporczywa kwestia: gdzie trafia przecinek na wielowierszowej liście kolumn?

-- Leading commas
SELECT
    id
  , email
  , created_at
FROM users;

-- Trailing commas
SELECT
    id,
    email,
    created_at
FROM users;

Przecinki na początku mają prawdziwą zaletę: dodanie lub usunięcie kolumny zmienia jedną linię, a brakujący przecinek jest łatwy do wypatrzenia, bo wadliwa linia się wyróżnia. Przecinki na końcu czytają się bardziej naturalnie i są w praktyce znacznie częstsze. Oba są w porządku — wybierz jeden i pozwól formaterowi go stosować, by nikt nie musiał o tym znów myśleć.

Konwencje nazewnictwa tabel i kolumn

Formatowanie rządzi białymi znakami; nazewnictwo rządzi samymi identyfikatorami, a przewodnik po stylu bez niego jest niekompletny.

De facto standardem dla identyfikatorów SQL jest snake_case — wszystko małymi literami, słowa oddzielone podkreśleniami: user_id, created_at, order_items. Zdobywa ten status z konkretnego powodu, nie tylko z przyzwyczajenia: identyfikatory w snake_case nigdy nie wymagają cudzysłowów i zachowują się spójnie w różnych dialektach, podczas gdy camelCase (powszechny w kodzie aplikacji) zderza się ze sposobem, w jaki bazy danych zwijają wielkość liter, do czego zaraz dojdziemy.

Warto wprost wyjaśnić, czym różni się to od kodu aplikacji. W większości języków programowania to otaczający kod kontroluje identyfikatory, a camelCase lub PascalCase jest normą. Identyfikatory SQL natomiast są interpretowane przez własne reguły zwijania wielkości liter bazy danych, a właśnie te reguły czynią nazwy o mieszanej wielkości liter kruchymi. snake_case omija cały ten problem: nie ma wielkości liter do zwinięcia ani powodu, by używać cudzysłowów, więc nic nie zachowuje się inaczej w różnych silnikach.

Kilka kolejnych konwencji, które pojawiają się niemal w każdym przewodniku po stylu SQL:

• Liczba pojedyncza vs mnoga w nazwach tabel to prawdziwy podział. users (mnoga, „tabela przechowuje użytkowników”) i user (pojedyncza, „każdy wiersz to użytkownik”) mają oboje swoich zwolenników. Podobnie jak wielkość liter, wybór ma mniejsze znaczenie niż konsekwentne stosowanie go do każdej tabeli.
• Unikaj słów zarezerwowanych jako identyfikatorów. Nazwanie kolumny order, user lub table zmusza cię do używania cudzysłowów wszędzie i zaprasza mylące błędy. Sięgnij po order_id lub account zamiast tego.
• Utrzymuj spójne nazewnictwo kluczy. Klucz główny nazwany id i klucze obce nazwane <referenced_table>_id (takie jak user_id) czynią złączenia przewidywalnymi i samoopisującymi.

Jest jedna pułapka warta wprost wskazania, bo gryzie zespoły, które nazywają kolumny bazy danych tak, jak nazywają zmienne aplikacji. W PostgreSQL niecytowany identyfikator jest zwijany do małych liter, więc SELECT userId FROM t faktycznie szuka kolumny o nazwie userid. W momencie, gdy ujmiesz go w cudzysłowy — "userId" — baza danych zachowuje wielkość liter i traktuje "userId" oraz userid jako dwie różne kolumny:

-- Creates a column whose real name is lowercase "userid"
CREATE TABLE t (userId integer);

-- Both of these work — the name was folded to lowercase
SELECT userId FROM t;
SELECT userid FROM t;

-- This fails: "column \"userId\" does not exist"
-- The quotes force an exact, case-sensitive match
SELECT "userId" FROM t;

Zwróć uwagę, że różne bazy danych zwijają wielkość liter w różnych kierunkach — Oracle zwija niecytowane identyfikatory do wielkich liter, kilka innych do małych — więc cytowane identyfikatory o mieszanej wielkości liter nie są nawet przenośne. Czystym wyjściem jest całkowite unikanie cytowanych identyfikatorów o mieszanej wielkości liter i trzymanie się snake_case, co omija cały problem i utrzymuje twój schemat czytelnym w każdym dialekcie.

Aby uzyskać głębsze porównanie camelCase, snake_case i kebab-case — w tym kiedy każdy z nich jest właściwym wyborem w kodzie i danych — zobacz przewodnik po konwencjach nazewnictwa.

Formatowanie w różnych dialektach SQL

Wszystko dotąd jest w dużej mierze niezależne od dialektu — wielkość liter, wcięcia, łamanie wierszy i nazewnictwo obowiązują niezależnie od tego, którą bazę danych obierasz za cel. Ale „sformatuj ten SQL” trafia na ścianę w momencie, gdy twoje zapytanie używa składni specyficznej dla jednej bazy danych, bo generyczny parser, który nie rozpoznaje tej składni, ją zniekształci: może podzielić token w złym miejscu, źle odczytać operator albo potraktować znak cudzysłowu jako ogranicznik łańcucha i połknąć połowę zapytania. To tutaj formatowanie świadome dialektu pokazuje swoją wartość, i to jest powód, dla którego formater prosi cię o wybranie bazy danych najpierw, zamiast zgadywać. Poniższe różnice to te, na które natrafiasz najczęściej w codziennych zapytaniach.

Operacja	PostgreSQL	MySQL / MariaDB	SQL Server (T-SQL)	Oracle	Standard SQL
Łączenie ciągów	|| lub CONCAT()	CONCAT()	+ lub CONCAT()	|| lub CONCAT()	||
Obsługa NULL	COALESCE()	COALESCE() / IFNULL()	COALESCE() / ISNULL()	COALESCE() / NVL()	COALESCE()
Ograniczanie wierszy	LIMIT	LIMIT	TOP / OFFSET … FETCH	FETCH FIRST	FETCH FIRST
Cytowanie identyfikatorów	cudzysłowy proste ("…")	backticki	nawiasy kwadratowe ([…])	cudzysłowy proste ("…")	cudzysłowy proste ("…")

Konkatenacja łańcuchów i obsługa NULL

Dwie z najczęstszych codziennych operacji są zapisywane różnie w różnych dialektach.

Konkatenacja łańcuchów:

-- PostgreSQL, Oracle, SQLite (standard operator)
SELECT first_name || ' ' || last_name AS full_name FROM users;

-- SQL Server (T-SQL uses +)
SELECT first_name + ' ' + last_name AS full_name FROM users;

-- Portable across dialects
SELECT CONCAT(first_name, ' ', last_name) AS full_name FROM users;

Wartości zastępcze dla NULL:

-- Standard SQL (works everywhere)
SELECT COALESCE(nickname, name) AS display_name FROM users;

-- SQL Server only
SELECT ISNULL(nickname, name) AS display_name FROM users;

-- MySQL / MariaDB only
SELECT IFNULL(nickname, name) AS display_name FROM users;

Formater ustawiony na zły dialekt może nie rozumieć ISNULL ani operatora || i może błędnie sparsować otaczające zapytanie.

Ograniczanie wierszy i cytowanie identyfikatorów

Ograniczanie wierszy wyniku to jeden z najbardziej rozbieżnych między dialektami kawałków składni:

-- PostgreSQL, MySQL, SQLite
SELECT id, name FROM users ORDER BY created_at DESC LIMIT 10;

-- SQL Server (T-SQL)
SELECT TOP 10 id, name FROM users ORDER BY created_at DESC;

-- Standard SQL / Oracle
SELECT id, name FROM users ORDER BY created_at DESC FETCH FIRST 10 ROWS ONLY;

Cytowanie identyfikatorów też rozchodzi się na trzy sposoby. Gdy musisz ująć identyfikator w cudzysłów — zwykle by użyć słowa zarezerwowanego lub zachować wielkość liter — ogranicznik zależy od bazy danych:

-- MySQL / MariaDB use backticks
SELECT `order`, `user` FROM `select`;

-- SQL Server (T-SQL) uses square brackets
SELECT [order], [user] FROM [select];

-- Standard SQL (PostgreSQL, Oracle, SQLite) uses double quotes
SELECT "order", "user" FROM "select";

Formater, który uważa, że backticki MySQL są ogranicznikami łańcucha, albo że nawiasy kwadratowe T-SQL są czymś innym, wyprodukuje uszkodzony wynik. Ustawienie dialektu jest tym, co mówi mu, co jest czym. To także powód, dla którego kopiowanie zapytania między bazami danych rzadko jest czystą podmianą: ta sama intencja logiczna — połącz dwa łańcuchy, zastąp NULL, ogranicz do dziesięciu wierszy, ujmij w cudzysłów słowo zarezerwowane — jest zapisana na cztery różne sposoby w różnych dialektach, i tylko parser, który zna twoją bazę danych, może przeformatować ją bez jej uszkodzenia.

Dlaczego formatowanie świadome dialektu ma znaczenie

To dokładnie powód, dla którego formater SQL jest dostarczany z dziewięcioma dialektami — PostgreSQL, MySQL, SQL Server (T-SQL), BigQuery, Snowflake, Oracle, SQLite, MariaDB i Standard SQL — zamiast jednego generycznego trybu. Wybranie właściwego oznacza, że parser poprawnie obsługuje łańcuchy cytowane dolarami w PostgreSQL i rzutowania ::, identyfikatory w nawiasach i TOP w T-SQL, funkcje specyficzne dla hurtowni w BigQuery i Snowflake oraz powyższe reguły cytowania, zamiast zgadywać i robić to źle. Wybierz swoją faktyczną bazę danych z listy rozwijanej przed formatowaniem, a wynik wróci poprawny i idiomatyczny.

Automatyzacja formatowania SQL

Czytanie reguł to jedno; nikt nie powinien stosować ich ręcznie. Cały sens przewodnika po stylu polega na tym, że egzekwuje go maszyna. Są trzy miejsca, w których można wpiąć formatowanie, zależnie od tego, ile tarcia chcesz usunąć.

W edytorze (formatowanie przy zapisie)

Opcją wymagającą najmniej wysiłku jest automatyczne formatowanie przy każdym zapisie. VS Code ma rozszerzenia formatera SQL działające przy zapisie, a JetBrains DataGrip oraz narzędzia bazodanowe w innych IDE są dostarczane z wbudowanym formaterem, który możesz przypisać do skrótu klawiszowego lub haka zapisu. Gdy już jest skonfigurowany, twoje zapytania po prostu nigdy nie są niesformatowane — ten sam model co Prettier dla JavaScriptu albo gofmt dla Go. Haczyk w tym, że ustawienia edytora żyją na maszynie każdego programisty, więc formatowanie przy zapisie utrzymuje twój SQL schludnym, ale samo w sobie nie gwarantuje, że reszta zespołu robi to samo. Do tego potrzebna jest następna warstwa.

W CI z linterem

By egzekwować styl w całym zespole, przenieś sprawdzenie do ciągłej integracji. Linter SQL taki jak sqlfluff zarówno lintuje, jak i automatycznie naprawia: kodujesz swoje reguły — dialekt, wielkość liter słów kluczowych, wcięcia, rozmieszczenie przecinków — w pliku konfiguracyjnym .sqlfluff, uruchamiasz sqlfluff lint, by oznaczyć naruszenia, i sqlfluff fix, by je naprawić, i sprawiasz, że CI odrzuca każdy pull request, który odbiega od uzgodnionego stylu. To ta sama idea co ESLint czy Prettier strzegące repozytorium frontendowego: styl przestaje być komentarzem do recenzji, który ktoś musi pamiętać zostawić, a staje się zaliczonym lub niezaliczonym sprawdzeniem, o którym maszyna nigdy nie zapomina. Wypłata jest taka, że spory o styl dzieją się raz, gdy piszesz konfigurację, zamiast przy każdym pull requeście.

Jednorazowe formatowanie online

Czasem masz po prostu jedno brzydkie zapytanie i żadnej ochoty niczego instalować — fragment z logu, wiadomość kolegi na Slacku, zapytanie, które wklejasz do dokumentacji. Do tego wklej je do formatera SQL, wybierz dialekt, wielkość liter i wcięcie, i skopiuj czysty wynik.

Szczegół dotyczący prywatności ma tu znaczenie i łatwo go przeoczyć. Wiele formaterów online wysyła wklejony przez ciebie tekst na serwer, by wykonać pracę, co oznacza, że kopia twojego zapytania — nazwy tabel, nazwy kolumn, czasem wartości literałów z produkcyjnego incydentu — opuszcza twoją maszynę. Formater SQL działa w całości w twojej przeglądarce, więc twój SQL nigdy nigdzie nie jest wysyłany. To sprawia, że bezpiecznie jest formatować zapytania dotykające produkcyjnych schematów lub zastrzeżonej logiki, co jest dokładnie tą sytuacją, w której najbardziej chcesz czystego formatowania, a najmniej chcesz oddawać swoje zapytanie stronie trzeciej. Jeśli zmagasz się z innymi formatami w tym samym przepływie pracy, bratni formatowanie JSON działa tak samo — to samo przetwarzanie w przeglądarce, to samo kopiowanie jednym kliknięciem.

Te trzy podejścia nie wykluczają się wzajemnie, a najlepsza konfiguracja zwykle łączy je: formatowanie przy zapisie dla szybkiej pętli wewnętrznej podczas pisania, linter w CI jako zabezpieczenie egzekwujące zespołowy standard i formater online dla jednorazowych fragmentów, które nigdy nie trafiają do repozytorium. Po cokolwiek sięgniesz, pamiętaj niezmiennik ostatni raz — żadne z tych narzędzi nie zmienia tego, co robi twoje zapytanie. Przestawiają białe znaki, łamanie wierszy, wielkość liter i komentarze, i nic więcej.

Najczęściej zadawane pytania

Czy słowa kluczowe SQL powinny być pisane wielkimi czy małymi literami?

Oba warianty są poprawne, bo słowa kluczowe SQL są niewrażliwe na wielkość liter. UPPERCASE sprawia, że słowa kluczowe wyróżniają się w środowiskach bez podświetlania składni, takich jak logi i diffy; lowercase jest łatwiejsze do wpisywania i pasuje do współczesnych edytorów, które już kolorują słowa kluczowe. To, co naprawdę ma znaczenie, to że cały zespół wybiera jeden wariant, a formater go egzekwuje — mieszana wielkość liter jest najgorszym wyborem.

Jakie wcięcie jest najlepsze dla SQL?

Dwie spacje to najczęstsze ustawienie domyślne i utrzymuje diffy zwarte; cztery spacje ułatwiają czytanie głęboko zagnieżdżonych zapytań; taby pozwalają każdemu programiście wybrać własną szerokość wyświetlania. Nie ma jednej poprawnej odpowiedzi — wybierz jedną i stosuj ją konsekwentnie w całym zespole. Większość formaterów SQL, w tym ten, obsługuje wszystkie trzy opcje.

Jak sformatować SQL automatycznie?

Są trzy sposoby na automatyczne formatowanie SQL: formatowanie przy zapisie w edytorze (VS Code lub DataGrip), linter w CI taki jak sqlfluff, który automatycznie naprawia styl, albo formater SQL online do jednorazowego wklejania. Droga online jest najszybsza, bo nie wymaga instalacji — wystarczy wkleić, wybrać dialekt i skopiować wynik.

Czy powinienem używać przecinków na początku czy na końcu w SQL?

Przecinki na początku (przecinek na początku każdej linii) dają czystsze diffy przy dodawaniu lub usuwaniu kolumn i sprawiają, że brakujący przecinek jest łatwy do wypatrzenia; przecinki na końcu (przecinek na końcu) czytają się bardziej naturalnie i są częstsze. Oba są akceptowalne w każdym przewodniku po stylu SQL — kluczem jest wybranie jednego i pozwolenie formaterowi stosować go automatycznie.

Czy formatowanie SQL zmienia sposób działania zapytania?

Nie. Formatowanie SQL zmienia tylko białe znaki, łamanie wierszy, wielkość liter słów kluczowych i komentarze — nigdy nie zmienia logiki zapytania. Sformatowane zapytanie zwraca dokładnie te same wyniki co oryginał, dlatego całkowicie bezpiecznie jest upiększać nawet produkcyjne zapytania przed ich recenzją lub uruchomieniem.

Jakiej konwencji nazewnictwa powinienem używać dla tabel i kolumn SQL?

snake_case — wszystko małymi literami z podkreśleniami — to de facto standard dla nazw tabel i kolumn SQL, bo unika cudzysłowów i pozostaje bezpieczny w różnych dialektach. Utrzymuj klucze główne (id) i klucze obce (user_id) nazwane spójnie i unikaj używania słów zarezerwowanych takich jak order czy user jako identyfikatorów, by zapobiec kłopotom z cudzysłowami.

Jak sformatować SQL dla konkretnego dialektu, takiego jak PostgreSQL czy T-SQL?

Wybierz najpierw pasujący dialekt w formaterze. Tryb PostgreSQL poprawnie obsługuje rzutowania :: i łańcuchy cytowane dolarami; tryb SQL Server (T-SQL) rozumie identyfikatory w nawiasach [identifiers] i TOP. Wybranie złego dialektu pozwala generycznemu parserowi zniekształcić składnię specyficzną dla dialektu, więc zawsze ustawiaj go na swoją faktyczną bazę danych przed formatowaniem.

Czy istnieje standardowy przewodnik po stylu SQL?

Nie ma oficjalnego standardu, ale istnieje kilka szeroko cytowanych: sqlstyle.guide Simona Holywella oraz publiczne przewodniki po stylu zespołów takich jak Mozilla i społeczność dbt. Ich wspólny konsensus — spójne wcięcia, identyfikatory w snake_case i łamanie wiersza przed każdą główną klauzulą — to właśnie to, co kodyfikuje ten przewodnik, a formater może to za ciebie egzekwować.