Formatowanie/upiększanie SQL

Formatowanie/upiększanie SQL to bezpłatne narzędzie, które przekształca kod SQL w bardziej czytelną i spójnie sformatowaną postać.

Co zmienia formatowanie SQL?

Formatowanie SQL zmienia sposób prezentacji zapytania, dzięki czemu łatwiej prześledzić jego klauzule, wyrażenia i zagnieżdżone struktury. Zwykle dodaje podziały wierszy i wcięcia między innymi w listach SELECT, klauzulach JOIN, warunkach WHERE, podzapytaniach i wyrażeniach CASE.

Formatowanie nie powinno zmieniać zamierzonego wyniku zapytania. Dialekty SQL różnią się jednak między sobą, a samo formatowanie nie daje pewności, że instrukcja zachowała swoje znaczenie. Przed uruchomieniem wygenerowanego SQL na danych produkcyjnych sprawdź go, szczególnie jeśli zawiera operatory specyficzne dla danego dostawcy, rozszerzenia proceduralne lub nietypowe reguły cytowania.

Formater przydaje się podczas analizowania zapytań pochodzących od innych osób, przeglądania wygenerowanego SQL, debugowania długiej instrukcji lub przygotowywania kodu do pull requestu. Spójny układ ułatwia też porównywanie zmian, ponieważ ogranicza nieistotne różnice w odstępach.

Jak sformatować SQL?

Wklej lub wpisz instrukcję w polu SQL, a następnie ją prześlij. Sformatowana wersja pojawi się w polu Upiększony SQL. Dane wejściowe są przesyłane do serwera przez HTTPS w celu przetworzenia i nie są przechowywane.

1. Skopiuj całą instrukcję wraz ze wszystkimi wyrażeniami common table expression, które chcesz zachować. W wyniku sprawdź komentarze oraz ewentualny średnik kończący instrukcję.
2. Wprowadź ją w polu SQL. Jeśli to możliwe, nie formatuj pojedynczych fragmentów wyrwanych z całości.
3. Przeczytaj wynik w polu Upiększony SQL, zwracając szczególną uwagę na zagnieżdżone wyrażenia i składnię właściwą dla danego dialektu.
4. Przed wdrożeniem uruchom sformatowaną instrukcję w odpowiednim środowisku deweloperskim lub testowym.

Jeśli pracujesz z poufnymi danymi w bazie, przed wysłaniem treści zapytania do narzędzia działającego na serwerze sprawdź zasady obowiązujące w Twojej organizacji. Usuń hasła, tokeny dostępu, dane osobowe i poufne wartości literałów, o ile nie są potrzebne do zrozumienia zapytania.

Jak czytać sformatowany SQL?

Analizuj wynik na podstawie wcięć i granic klauzul. Nowy układ nie jest dowodem na poprawność instrukcji. Klauzule najwyższego poziomu, takie jak SELECT, FROM, WHERE, GROUP BY i ORDER BY, zwykle łatwiej rozróżnić, gdy każda logiczna część znajduje się w osobnym wierszu lub na odpowiednim poziomie wcięcia.

• Podzapytania z wcięciem pokazują, gdzie wynik wewnętrznego zapytania jest wykorzystywany przez instrukcję zewnętrzną.
• Wyrównane warunki ułatwiają sprawdzanie kolejności wykonywania AND i OR. Domyślnie AND ma pierwszeństwo przed OR, a nawiasy nadal określają logiczne grupowanie.
• Rozdzielone klauzule JOIN pomagają ustalić, który warunek ON należy do danej tabeli.
• Rozwinięte listy SELECT ułatwiają zauważenie brakujących przecinków, powtórzonych kolumn i niejednoznacznych aliasów.
• Wyraźnie widoczne gałęzie CASE pomagają dopasować słowa kluczowe WHEN, THEN, ELSE i END.

Ciągi w cudzysłowach, liczby, znaki interpunkcyjne i komentarze mają w SQL znaczenie, dlatego sprawdź je, zamiast zakładać, że wpływają wyłącznie na wygląd kodu. Znaki diakrytyczne i znaki spoza alfabetu łacińskiego mogą być prawidłowe w literałach tekstowych oraz cytowanych identyfikatorach, zależnie od bazy danych i używanego kodowania znaków.

Krótkie przykłady formatowania

Weźmy takie zwarte dane wejściowe.

Input: SELECT id,name FROM customers WHERE active=1 ORDER BY name;

Czytelna, sformatowana wersja może wyglądać tak.

Output: SELECT id, name

FROM customers

WHERE active = 1

ORDER BY name;

W zapytaniu ze złączeniem wcięcia dają jeszcze większą korzyść.

Input: SELECT o.id,c.name FROM orders o JOIN customers c ON c.id=o.customer_id WHERE o.total>100;

W czytelnym wyniku SELECT, FROM, JOIN, ON i WHERE mogą znaleźć się w osobnych wierszach, przy zachowaniu porównania o.total > 100. Dokładna wielkość liter, odstępy i podział na wiersze zależą od przyjętych zasad formatowania. Traktuj więc te przykłady jako możliwe układy, a nie gwarantowany standard zapisu.

Czy formatowanie wykrywa błędy SQL?

Nie. Upiększanie SQL nie jest tym samym co sprawdzanie instrukcji za pomocą parsera bazy danych. Wynikiem działania tego narzędzia jest sformatowany SQL, dlatego nie należy traktować go jako narzędzia do kontroli składni, sprawdzania schematu ani tworzenia planu wykonania.

Czytelniejszy układ może jednak pomóc zauważyć prawdopodobne błędy podczas przeglądu. Typowe przykłady to brak przecinka na liście SELECT, niedomknięte nawiasy, niezamknięty ciąg w cudzysłowie, JOIN bez zamierzonego warunku albo nieprawidłowe grupowanie wyrażeń AND i OR. Łatwiej można też dostrzec słowo zastrzeżone użyte jako identyfikator bez cytowania.

Niektórych problemów nie da się stwierdzić bez docelowej bazy danych. Instrukcja akceptowana przez PostgreSQL może wymagać zmian w Microsoft SQL Server, MySQL, Oracle Database lub SQLite. Brakujące tabele, nieznane kolumny, niezgodne typy danych i błędy uprawnień zwykle trzeba diagnozować za pomocą silnika bazy danych albo narzędzia deweloperskiego obsługującego dany dialekt.

Kiedy nie warto formatować SQL?

Formatowanie zwykle nie jest potrzebne, jeśli SQL ma już spójny układ albo będzie odczytywany wyłącznie przez maszynę. Ponowne formatowanie wygenerowanych zapytań może powodować wiele nieistotnych zmian w systemie kontroli wersji, nie poprawiając przy tym generatora, który je utworzył.

Formatowanie może też nie być właściwym krokiem w następujących sytuacjach:

• Plik migracji został podpisany, opatrzony sumą kontrolną lub jest w inny sposób porównywany bajt po bajcie.
• Zminimalizowane lub zwarte zapytanie jest osadzone w artefakcie o ścisłym limicie rozmiaru i nikt nie musi go przeglądać.
• Bieżące zadanie dotyczy walidacji, analizy planu wykonania lub optymalizacji wydajności, a nie czytelności.
• Zapytanie zawiera poufne wartości, których zgodnie z zasadami organizacji nie wolno wysyłać do usługi działającej na serwerze.

Jeśli chcesz powtarzalnie formatować całe repozytorium, lepszym rozwiązaniem może być formater wiersza poleceń obsługujący konkretny dialekt, ponieważ jego konfigurację można umieścić w repozytorium razem z kodem. W przypadku strukturalnych danych API zawierających SQL Walidator i upiększacz JSON może pomóc przeanalizować otaczający kod JSON, ale sam SQL nadal wymaga narzędzia przeznaczonego do tego języka.

Najczęstsze pytania

Czy formatowanie SQL zmienia działanie NULL?

Odstępy i wcięcia nie zmieniają trójwartościowej logiki SQL ani zachowania NULL. Mimo to sprawdź wyrażenia takie jak column = NULL, które zwykle wymagają IS NULL, ponieważ formater nie poprawi tego błędu semantycznego.

Czy mogę sformatować kilka instrukcji SQL naraz?

Obsługa kilku instrukcji SQL jednocześnie nie jest udokumentowana. Formatuj każdą instrukcję osobno.

Czy mogę zostawić komentarze w danych wejściowych?

Komentarze mogą zawierać odwołania do zgłoszeń, wewnętrzne nazwy hostów, dane klientów lub notatki operacyjne, nawet jeśli wykonywalny SQL nie zawiera poufnych literałów. Przed wysłaniem treści do serwera sprawdź zarówno komentarze wierszowe, jak i blokowe.

Czy słowa kluczowe SQL pisać wielkimi, czy małymi literami?

Oba style są zazwyczaj poprawne, ponieważ wiele silników baz danych nie rozróżnia wielkości liter w niecytowanych słowach kluczowych. Stosuj konwencję przyjętą w repozytorium. Zachowaj ostrożność przy cytowanych identyfikatorach, ponieważ niektóre bazy danych zachowują lub rozróżniają ich wielkość liter.

Co sprawdzić przed uruchomieniem sformatowanego zapytania?

Potwierdź dialekt docelowej bazy danych, sprawdź warunki WHERE i JOIN oraz zweryfikuj granice transakcji dla instrukcji UPDATE, DELETE i instrukcji zmieniających schemat. Ryzykowne zapytania najpierw uruchamiaj w deweloperskiej lub testowej bazie danych, najlepiej z reprezentatywnymi danymi i odpowiednimi kopiami zapasowymi.