Czym różnią się dialekty? Czy nie wystarczy "Standard SQL"?

Każdy producent bazy dodał swoje rozszerzenia. **PostgreSQL** ma `RETURNING`, `::` rzutowania i CTE typu `WITH RECURSIVE`. **MySQL** ma `LIMIT offset, count` i backticki na identyfikatory. **MSSQL (T-SQL)** ma `TOP N` zamiast `LIMIT` i `[nawiasy kwadratowe]`. **BigQuery** używa `STRUCT` i `ARRAY`. Wybór dialektu wpływa na to, jak formater traktuje te konstrukcje.

Co znaczy "pozycja przecinka: before"?

Klasycznie SQL pisze się z przecinkiem na końcu linii: `id,\n name,\n email`. **Wariant "before"** stawia przecinek na początku następnej linii: `id\n , name\n , email`. Zaleta: dodanie/usunięcie ostatniej kolumny nie zmienia poprzedniej linii, więc diff w Git jest czystszy. Wymaga przyzwyczajenia, ale wielu architektów baz danych właśnie tak pisze.

**Usuwa komentarze** (zarówno `-- linia` jak i `/* blok */`), **łączy wszystkie linie** w jedną i **redukuje wielokrotne spacje** do jednej. Wynik jest najkrótszą poprawną wersją zapytania. Używaj, kiedy wklejasz SQL do stringa w kodzie aplikacji albo logujesz pojedynczą linią.

Czy zachowa moje komentarze?

W trybie **Format** tak. Komentarze `--` i `/* */` zostają, formater stara się je rozsądnie wciągnąć do nowego układu. W trybie **Minify** komentarze są usuwane razem z białymi znakami.

Dlaczego po sformatowaniu mam dziwne nowe linie w środku string-literala?

Formater **nigdy nie modyfikuje stringów** wewnątrz cudzysłowów. Jeśli widzisz nowe linie w stringu, to znaczy że były tam już wcześniej. To sygnał, że oryginalny SQL miał wielo-liniowy string (czasem zamierzony, czasem przypadkowy).

Co zrobić, gdy formater zgłasza błąd składniowy?

Po pierwsze: sprawdź **dialekt**. Jeśli używasz `LIMIT 10 OFFSET 5` to PostgreSQL/MySQL/SQLite, a nie MSSQL (T-SQL używa `OFFSET ... ROWS FETCH NEXT ... ROWS ONLY`). Po drugie: usuń stopniowo fragmenty, żeby znaleźć linijkę powodującą problem. Czasem zawiera niedomknięty cudzysłów albo znak `;` w środku stringa.

Czy obsługuje procedury, triggery i funkcje?

Tak, ale **wsparcie jest zależne od dialektu**. PL/SQL (Oracle) i T-SQL (MSSQL) są obsługiwane całkiem dobrze. PostgreSQL [[PL/pgSQL||rozszerzenie do pisania funkcji w Postgres]] formatuje się gorzej, bo body funkcji jest osadzone jako string. W praktyce: sformatuj główny szkielet, body funkcji popraw ręcznie.

Mam tysiące linii SQL. Czy to się nie zatka?

Plik na 10-20 tysięcy linii sformatuje się w ułamku sekundy. Naprawdę duże pliki (setki tysięcy linii) mogą chwilę zająć, bo wszystko jest synchroniczne i blokuje wątek przeglądarki. W praktyce sensowny limit to **kilkadziesiąt tysięcy linii** na jeden wsad.

Czy mogę użyć tego formatera w swoim CI/CD jako sprawdzenie stylu kodu SQL?

Bezpośrednio z tej strony nie. Pod spodem używamy paczki **`sql-formatter`** z npm, którą możesz dodać sobie do projektu (`npm install sql-formatter`) i puścić w pre-commit hooku albo GitHub Actions. Dokładnie taki sam wynik, tylko lokalnie.

YourDevToolsPro

Formater SQL

Wklej brzydkie zapytanie SQL, dostań elegancko sformatowane. PostgreSQL, MySQL, SQLite, MSSQL, BigQuery, Oracle. Wszystko po stronie przeglądarki.

LiveDziała w przeglądarce

Dialekt

Słowa kluczowe

Przecinki

Wcięcie

Pusta linia między zapytaniamiDwie puste linie między oddzielnymi zapytaniami

Wejściowy SQL1 linii / 222 B

Sformatowany SQL

20 linii / 248 B

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

Wejście (linie)

Wynik (linie)

Wejście (rozmiar)

222 B

Wynik (rozmiar)

248 B

Co robi formater SQL?

Wklejasz długie zapytanie SQL bez wcięć i nowych linii. Dostajesz czytelnie sformatowane zapytanie z wcięciami, słowami kluczowymi pisanymi wielkimi literami i sensownym układem kolumn. To samo, co robi Prettier dla JavaScripta, tylko dla SQL.

Wybierasz dialekt (PostgreSQL, MySQL, SQLite, MSSQL, BigQuery, MariaDB, Oracle), bo każda baza ma własne słowa kluczowe i drobne różnice w składni. Możesz ustawić wielkość liter słów kluczowych (UPPER vs lower), pozycję przecinka (po kolumnie albo na początku następnej linii) oraz szerokość wcięcia.

Tryb minify robi odwrotnie: usuwa komentarze, łączy wszystko w jedną linię. Przydaje się, kiedy wklejasz zapytanie do logów albo do kodu w stringu.

Jak korzystać

Wklej zapytanie SQL w lewe pole. Może być w jednej linii, bez wcięć, w mieszanej wielkości liter, nieważne.
Wybierz dialekt swojej bazy danych z listy. Dla PostgreSQL wybierz PostgreSQL, dla MySQL/MariaDB wybierz odpowiedni wariant.
Zdecyduj o wielkości liter słów kluczowych: `UPPER` (klasyka), `lower` (popularny w nowoczesnych zespołach) albo `preserve` (zostaw jak było).
Wybierz pozycję przecinka: `after` (przecinek na końcu linii, klasycznie) albo `before` (na początku następnej linii, łatwiej dodać/usunąć kolumnę bez psucia diffa).
Skopiuj wynik przyciskiem Kopiuj. Wklej do swojego IDE, narzędzia do migracji, do dokumentacji.
Tryb Minify zwija zapytanie do jednej linii. Użyj, kiedy chcesz wkleić SQL do stringa w kodzie albo do logu.

Do czego się przydaje

Typowe sytuacje, kiedy formater SQL oszczędza czas:

Code review kolegi, który wkleił zapytanie w jednej linii. Wklejasz, formatujesz, czytasz spokojnie co się dzieje.
Migracja bazy danych wymaga pliku z dziesiątkami CREATE TABLE i ALTER. Po formatowaniu plik jest gotowy do PR-a.
Debug zapytań z ORM-a (Prisma, TypeORM, Drizzle). ORM-y generują SQL w jednej długiej linii. Formater pokazuje co naprawdę poszło do bazy.
Dokumentacja techniczna, raport, prezentacja. Sformatowany SQL wygląda profesjonalnie.
Przenoszenie SQL między dialektami. Najpierw sformatuj w jednym dialekcie, potem użyj naszego konwertera dialektów SQL, żeby zamienić AUTO_INCREMENT na SERIAL itp.
Minify do logów albo do stringa w kodzie: jedna długa linia, bez komentarzy, gotowa do wklejenia w `db.query('...')` w Node.js lub Pythonie.

Jeśli masz CREATE TABLE i chcesz schemat dla Prismy albo Drizzle ORM, użyj konwertera SQL na ORM. Jeśli pracujesz z DBML (Database Markup Language), zobacz DBML na SQL.

Pytania i odpowiedzi

Nie. Cały formater działa po stronie przeglądarki, w JavaScripcie. Nic nie idzie na żaden serwer. Możesz nawet wyłączyć internet po załadowaniu strony, formater dalej będzie działał.

Mogą Cię też zainteresować

Powiązane narzędzia

Konwerter dialektów SQL

Zamień SQL z MySQL na PostgreSQL, z MSSQL na Oracle, w dowolną stronę. Auto-increment, BOOLEAN, LIMIT vs TOP, ||, NOW.

Konwerter SQL na ORM

Wklej CREATE TABLE, dostań schemat dla Prisma, Drizzle, TypeORM albo Sequelize. Mapowanie typów, relacje, default-y.

Konwerter DBML na SQL

Wklej DBML (Database Markup Language), dostań CREATE TABLE w PostgreSQL, MySQL albo SQLite. Wszystko po stronie przeglądarki.

Parser connection stringa do bazy

Wklej URL połączenia z bazą (PostgreSQL, MySQL, MongoDB, Redis, JDBC), dostań rozbity widok pól. Lub zbuduj URL z formularza.