Mówią, że się nie da, ale czasem da się.
Przytrafiło mi się jakiś czas temu w pracy, że znów - jak za starych, dobrych czasów - piszę dużo kodu SQL. Kod ów działa lepiej lub gorzej, ale ja dziś nie o tym.
Dziś - o formatowaniu.
Szkół jest kilka. W odróżnieniu od takiego, dajmy na to, Pythona, Javy czy C#, gdzie format kodu został zestandaryzowany wieki temu i wszyscy się tego standardu (pi x oko) trzymają, o tyle w przypadku SQL programiści nie mogą się dogadać i każdy ciągnie w swoją stronę.
Pociągnę więc i ja.
Jakiś czas temu odkryłem stronę SQL Style Guide, która pokazuje pewien konkretny styl formatowania zapytań SQL, zaproponowany przez Simona Holywella. Bardziej z nudów i dla hecy niż z przekonania zacząłem przerabiać niektóre ze swoich zapytań na ten właśnie styl - i kliknęło!
Tajemnica polega na tym, że tworzymy rzeki.
Rzeki w tym konkretnym kontekście nie są wprawdzie tak piękne, jak w powyższej piosence - ale jednak są całkiem niebrzydkie.
Przykład:
SELECT tytuł
, autor
, rok_wydania
FROM książki
WHERE tytuł = 'Cyberiada';
Widać? No przecież, że widać. Po słowie kluczowym pojawia się pionowa "rzeka", wszystko na lewym brzegu jest wyrównane do prawej i vice versa.
Weźmy odrobinę bardziej skomplikowany przypadek:
SELECT B.title AS BookTitle
, A.name AS AuthorName
, L.language AS Language
FROM books AS B
INNER JOIN authors AS A
ON B.author_id = A.id
INNER JOIN languages AS L
ON B.language_id = L.id
WHERE A.active = 1
ORDER BY B.title;
Oczywiście czym dłuższe zapytanie, tym trudniej utrzymać "rzekę" w jednym kawałku, dlatego czasem trzeba podjąć decyzję o "złamaniu" rzeki:
WITH UpdatedBooks AS (
SELECT B.id AS BookID
, B.title AS NewTitle
FROM books AS B
INNER JOIN authors AS A
ON B.author_id = A.id
WHERE A.active = 0
AND B.updated_at < DATEADD(year, -1, GETDATE())
UNION ALL
SELECT B.id
, B.title
FROM books AS B
INNER JOIN languages AS L
ON B.language_id = L.id
WHERE L.language = 'English'
AND B.pages > 300
)
UPDATE B
SET B.title = U.NewTitle
FROM books AS B
INNER JOIN UpdatedBooks AS U
ON B.id = U.BookID
WHERE B.title != U.NewTitle;
W ostatnim przykładzie mamy dwie "rzeki": jedna wewnątrz podzapytania CTE, druga na końcu. No i sama linia otwierająca CTE również nie jest częścią "rzeki". Niektórzy idą w skrajność i przesuwają słówko "WITH" żeby "pasowało", ale osobiście uważam powyższy wariant za bardziej czytelny.
WITH UpdatedBooks AS ( -- tu WITH kończy się na wysokości SELECT
SELECT B.id AS BookID
, B.title AS NewTitle
FROM books AS B
...
Gwoli ścisłości, podlinkowana na początku artykułu strona o formatowaniu kodu SQL mówi nie tylko o "rzekach", ale również wielu innych elementach, które jednak postanowiłem zignorować, bo mi się tak podoba.
A Ty, Czytelniku, jak formatujesz swój kod SQL?
Nie formatuję w ogóle, bo nie umiem w bazodanowe relacje, ale chcę się wkrótce nauczyć. Na start polecasz eksperymenty z MySQL czy od razu PostgreSQL?
Na start polecam próbę rozwiązania jakiegoś konkretnego problemu. Uczenie się samego SQL-a (czy dowolnej innej technologii komputerowej) „na sucho” tj. bez konkretnej potrzeby na ogół nie zdaje egzaminu.
Rzekłszy jednakowoż powyższe oraz zerknąwszy we własną przeszłość, gdybym dziś startował w te klocki i miałbym wybrać między tymi dwoma silnikami, postawiłbym na PG.
Miej też na uwadze, że poszczególne dialekty SQL w warstwie podstawowej nie różnią się między sobą aż tak bardzo. Jeżeli załapiesz podstawy na PGSQL, powinieneś w miarę bezproblemowo przesiąść się na MySQL, SQLite czy cokolwiek innego. Oczywiście jak się zaczniesz zagłębiać w bardziej zaawansowane kawałki, prędzej czy później odkryjesz spore różnice, ale podstawy są tu i tam te same.
Sam rzeźbię od lat w MSSQL, gdzieś tam po drodze miałem krótką przygodę z MySQL oraz nieco dłuższą z Oracle, ale MSSQL zawsze do mnie wraca, jak bumerang.
Formatowanie SQL dla mnie powinno być takie aby:
– widać jasno boki
– widać zagnieżdżenia bloków (co jest wewnątrz czego)
– widać części warunków – odpowiednie ułożenie zagnieżdżonych warunków np. AND na początek
Do tego dochodzą kwestie estetyczne jak pokazałeś:
– równać do lewej czy do środka.
To są już rzeczy jak komu pasuje. Mam doczynienia zazwyczaj z kilkudziesięcioma/kilkuset linijkowymi wykwitami także chyba mam doświadczenie.
… Jednak przecinki przed wg mnie są jakimś antywzorcem (mimo, że jak dopisujemy coś to ruszamy tylko właściwą linie, a nie linie przed). Moje serce roni łzy na sam widok.
Niezbyt mi się to widzi. Po pierwsze, wyrównywanie słów na początku do prawej jest niewygodne, bo trzeba każdorazowo brać pod uwagę ile liter ma dane słowo. W ogóle zresztą wszelkie wyrównywanie słów ma ten feler, że jak kiedyś dodasz nowe, dłuższe od któregokolwiek z obecnych, to trzeba poprawiać całość. Po drugie, przecinki na początku linijek to zło i niekonsekwencja, skoro pierwsza kolumna jest w linii z SELECT – już lepiej mieć każdą kolumnę w nowej linijce i przecinek na końcu (fakt, wtedy dla odmiany jest niekonsekwencja z brakiem przecinka po ostatniej kolumnie, bo SQL nie ogarnia nadmiarowych przecinków, niemiło z jego strony). Po trzecie, logika jest zaburzona przez przypadki typu INNER JOIN czy UNION ALL, które powinny być w całości po lewej, a nie przedzielone „rzeką” pośrodku. Po czwarte i najpoważniejsze, w tym układzie całkowicie nieczytelna jest hierarchia elementów, np. UNION ALL zaczyna się gdzieś pośrodku i w ogóle nie rzuca się w oczy. Zalet za bardzo nie widzę, poza tym że można sobie narysować ładną pionową kreskę na screenshocie – co chyba jednak wad nie równoważy.
Wyrównanie „do środka” spotkałem produkcyjnie prawie 20 lat temu i czuję, że to było odziedziczone z poprzednich języków przed SQL.
Wygląda to ładnie, gdyby zapytanie się nie zmieniało w czasie (lub gdybyśmy pracowali bez systemu kontroli wersji, co pewnie kiedyś było czymś częstym, i mielibyśmy czas na taką rearanżację całości). Byłoby jak w książce.
No i gdyby edytor to wspierał i sam wyrównywał w ten sposób.
Większość nowych osób w zespole wyrównywało do lewej.