Czy to działa w 100% poprawnie? Mogę puścić wynik wprost do produkcji?

**Nie. Zawsze sprawdź wynik.** Narzędzie używa zestawu regexów i reguł, które pokrywają najczęstsze różnice. Złożone konstrukcje (procedury, [[CTE||Common Table Expression, zapytanie z WITH]] rekurencyjne, funkcje okienkowe z OVER) mogą wymagać ręcznej korekty. Traktuj to jako solidne 80%, nie 100%.

Co konkretnie przepisuje?

Najważniejsze rzeczy: **klucze auto-inkrementowane** (AUTO_INCREMENT / SERIAL / IDENTITY / GENERATED AS IDENTITY), **typy BOOLEAN** (BOOL / BIT / TINYINT(1) / NUMBER(1)), **paginacja** (LIMIT/OFFSET ↔ TOP ↔ FETCH NEXT), **typy tekstowe** (TEXT / LONGTEXT / CLOB / VARCHAR(MAX)), **typy czasu** (TIMESTAMP / DATETIME / DATETIME2 / TIMESTAMPTZ), **funkcje czasu** (NOW / GETDATE / SYSDATE / CURRENT_TIMESTAMP), **konkatenacja stringów** (`||` ↔ CONCAT), **cudzysłowy identyfikatorów** (backtick / bracket / double-quote), **klauzule MySQL** (ENGINE=InnoDB).

Dlaczego LIMIT/OFFSET nie istnieje w MSSQL?

Historycznie MSSQL miał tylko `SELECT TOP N` (bez offsetu). W 2012 dodano `OFFSET ... ROWS FETCH NEXT ... ROWS ONLY`, składnię SQL standardu. Konwerter używa **TOP N** kiedy nie ma offsetu i **OFFSET/FETCH NEXT** kiedy jest. PostgreSQL/MySQL/SQLite używają wygodniejszej składni `LIMIT N OFFSET M`.

Czemu BOOLEAN w MySQL to TINYINT(1)?

**MySQL nie ma natywnego BOOLEAN-a.** Słowo kluczowe BOOLEAN jest aliasem na TINYINT(1), gdzie 0 = false, każda inna wartość = true. PostgreSQL ma prawdziwy typ BOOLEAN. MSSQL ma BIT (0/1). Oracle ma NUMBER(1) konwencjonalnie. BigQuery ma BOOLEAN. Konwerter dostosowuje typ + literały TRUE/FALSE → 1/0 tam, gdzie trzeba.

Po co zmieniać `||` na CONCAT?

W **PostgreSQL, Oracle, SQLite** operator `||` to konkatenacja stringów: `'a' || 'b' = 'ab'`. Ale w **MySQL** `||` to logiczne OR (jak `OR`), więc `'a' || 'b'` zwraca **0**, nie "ab". Konieczne jest `CONCAT('a', 'b')`. Konwerter przepisuje w obie strony, w zależności od kierunku.

Czemu MySQL używa backticków, a MSSQL nawiasów kwadratowych?

Identyfikatory (nazwy tabel, kolumn) trzeba czasem brać w cudzysłowy, np. kiedy zawierają spację albo kolidują ze słowem kluczowym. **Standard SQL** używa `"podwójnych cudzysłowów"`. **MySQL** używa `backticków` (bo `"` mu już rezerwują stringi). **MSSQL** używa `[nawiasów kwadratowych]` z historycznych powodów. Konwerter dostosowuje styl do docelowego dialektu.

Czy konwertuje IF NOT EXISTS?

PostgreSQL, MySQL, MariaDB i SQLite obsługują `CREATE TABLE IF NOT EXISTS`. **Oracle nie obsługuje** tej składni, **MSSQL też nie** dla większości obiektów. Konwerter wycina `IF NOT EXISTS` i dodaje komentarz przypominający, żebyś sam owinął to w `IF NOT EXISTS (...) BEGIN ... END` w MSSQL albo `EXECUTE IMMEDIATE` w Oracle.

Czemu wynik nie zachował moich komentarzy w idealnym miejscu?

Konwersja jest reglowana (regex-owa), a komentarze są wrażliwe na kontekst. Staramy się je zachować, ale układ może się przesunąć po reformatowaniu. **Wyłącz auto-formatowanie** w opcjach, jeśli chcesz dostać wynik bez zmiany układu.

Czy obsługuje funkcje, triggery, widoki?

Częściowo. **Widoki (CREATE VIEW)** zwykle działają, bo to po prostu owinięty SELECT. **Funkcje i procedury** są bardziej skomplikowane, bo każdy dialekt ma własny język proceduralny (PL/pgSQL, T-SQL, PL/SQL, MySQL stored procedures). Ich body **nie konwertujemy** w pełni. Konwertuj szkielet, body przepisz ręcznie.

Czy moja baza danych nigdzie nie wycieka?

Wszystko działa w przeglądarce. Konwersja jest po stronie klienta, w JavaScripcie. Żadne zapytania nie idą na serwer. Możesz nawet wyłączyć WiFi po załadowaniu strony.

Konwerter dialektów SQL - darmowy

Z dialektu

Na dialekt

Formatuj wynik

Wejście (MySQL)

Wynik (PostgreSQL)

CREATE TABLE IF NOT EXISTS users (
  id INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email VARCHAR(255) NOT NULL,
  is_active TINYINT (1) NOT NULL DEFAULT 1,
  bio TEXT,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

SELECT
  "id",
  "email"
FROM
  "users"
WHERE
  is_active = TRUE
LIMIT
  20
OFFSET
  0;

Zastosowane zmiany8 zmian

1
Klucz auto-inkrementowany
(AUTO_INCREMENT / SERIAL / IDENTITY ...)GENERATED ALWAYS AS IDENTITY
2
MySQL-owy LIMIT offset, count
LIMIT 0, 20LIMIT 20 OFFSET 0
3
Typ tekstowy
LONGTEXTTEXT
4
Typ czasu
DATETIMETIMESTAMPTZ
5
Klauzula ENGINE (MySQL)
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4(dropped, MySQL-specific)
6
Cudzysłowy identyfikatorów
`id`"id"
7
Cudzysłowy identyfikatorów
`email`"email"
8
Cudzysłowy identyfikatorów
`users`"users"

Po co konwerter dialektów SQL?

Każda baza danych ma własną odmianę SQL. PostgreSQL używa `SERIAL` na klucz auto-inkrementowany, MySQL używa `AUTO_INCREMENT`, MSSQL używa `IDENTITY(1,1)`, Oracle `GENERATED AS IDENTITY`. Standard SQL jest tylko teorią, w praktyce każdy producent dorzucił własne rozszerzenia.

Wklejasz zapytanie z jednej bazy, wybierasz dialekt źródłowy i docelowy, a narzędzie zamienia różniące się konstrukcje: typy kolumn (TINYINT vs BOOLEAN vs BIT vs NUMBER(1)), klucze auto-inkrementowane, paginację (`LIMIT/OFFSET` vs `TOP` vs `FETCH NEXT`), funkcje czasu (`NOW()` vs `GETDATE()` vs `SYSDATE`), konkatenację stringów (`||` vs `CONCAT()`), cudzysłowy identyfikatorów (`` `id` `` vs `[id]` vs `"id"`).

Po prawej widzisz listę zastosowanych zmian z krótkim wyjaśnieniem, dlaczego coś zostało przepisane. To nie jest magia, tylko przyzwoita lista reguł, które pokrywają ~80% portowania prostych schematów.

Jak korzystać

Wybierz dialekt źródłowy (z jakiej bazy pochodzi zapytanie) i docelowy (do jakiej bazy chcesz przenieść).

Wklej zapytanie SQL do lewego pola. Może to być `CREATE TABLE`, `SELECT`, `INSERT`, cokolwiek.

W prawym polu zobaczysz wynik konwersji, automatycznie sformatowany dla docelowego dialektu.

Pod spodem masz listę dokonanych zmian: każda reguła z porównaniem "przed" i "po", razem z opisem.

Skopiuj wynik przyciskiem Kopiuj. Sprawdź, czy logika jest zachowana (regex nie potrafi wszystkiego, czasem trzeba doszlifować ręcznie).

Możesz zamienić źródło z celem przyciskiem ze strzałkami w lewo-prawo. Przydatne, kiedy chcesz przekonwertować w obie strony.

Do czego się przydaje

Najczęstsze scenariusze:

Migracja z MySQL do PostgreSQL. Klasyk: firma rośnie, MySQL przestaje wystarczać, przechodzicie na Postgres. Schemat tabel trzeba przepisać. To narzędzie załatwia 80% rutyny.
Wsparcie dwóch baz w jednym ORM-ie. Pracujesz z Prisma albo Drizzle, klient ma MSSQL, lokalnie używasz PostgreSQL. Trzeba mieć dwie wersje skryptu inicjalizacyjnego.
Tworzenie BigQuery z istniejącej bazy operacyjnej. Schemat z MySQL trzeba dostosować do BigQuery, gdzie nie ma AUTO_INCREMENT i typów się dużo różni.
Code review zapytania od kolegi, który pisze pod inny silnik. Szybko sprawdzasz, czy zadziała w Twojej bazie.
Nauka różnic między dialektami. Wklej proste zapytanie, przełączaj dialekty docelowe i obserwuj, co się zmienia. Lepsze niż czytanie suchych dokumentacji.
Test portability istniejącego schematu. Konwersja pokazuje, gdzie używasz konstrukcji specyficznych dla jednego producenta.

Po konwersji warto sformatować wynik, używając naszego formatera SQL. Jeśli chcesz schemat dla ORM-a, mamy konwerter SQL na ORM.

Pytania i odpowiedzi

Nie. Zawsze sprawdź wynik. Narzędzie używa zestawu regexów i reguł, które pokrywają najczęstsze różnice. Złożone konstrukcje (procedury, CTE rekurencyjne, funkcje okienkowe z OVER) mogą wymagać ręcznej korekty. Traktuj to jako solidne 80%, nie 100%.

CREATE TABLE IF NOT EXISTS users ( id INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY, email VARCHAR(255) NOT NULL, is_active TINYINT (1) NOT NULL DEFAULT 1, bio TEXT, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); SELECT "id", "email" FROM "users" WHERE is_active = TRUE LIMIT 20 OFFSET 0;

Po co konwerter dialektów SQL?

Jak korzystać

Wybierz dialekt źródłowy (z jakiej bazy pochodzi zapytanie) i docelowy (do jakiej bazy chcesz przenieść).

Wklej zapytanie SQL do lewego pola. Może to być `CREATE TABLE`, `SELECT`, `INSERT`, cokolwiek.

W prawym polu zobaczysz wynik konwersji, automatycznie sformatowany dla docelowego dialektu.

Pod spodem masz listę dokonanych zmian: każda reguła z porównaniem "przed" i "po", razem z opisem.

Skopiuj wynik przyciskiem Kopiuj. Sprawdź, czy logika jest zachowana (regex nie potrafi wszystkiego, czasem trzeba doszlifować ręcznie).

Możesz zamienić źródło z celem przyciskiem ze strzałkami w lewo-prawo. Przydatne, kiedy chcesz przekonwertować w obie strony.

Do czego się przydaje

Najczęstsze scenariusze:

Migracja z MySQL do PostgreSQL. Klasyk: firma rośnie, MySQL przestaje wystarczać, przechodzicie na Postgres. Schemat tabel trzeba przepisać. To narzędzie załatwia 80% rutyny.
Wsparcie dwóch baz w jednym ORM-ie. Pracujesz z Prisma albo Drizzle, klient ma MSSQL, lokalnie używasz PostgreSQL. Trzeba mieć dwie wersje skryptu inicjalizacyjnego.
Tworzenie BigQuery z istniejącej bazy operacyjnej. Schemat z MySQL trzeba dostosować do BigQuery, gdzie nie ma AUTO_INCREMENT i typów się dużo różni.
Code review zapytania od kolegi, który pisze pod inny silnik. Szybko sprawdzasz, czy zadziała w Twojej bazie.
Nauka różnic między dialektami. Wklej proste zapytanie, przełączaj dialekty docelowe i obserwuj, co się zmienia. Lepsze niż czytanie suchych dokumentacji.
Test portability istniejącego schematu. Konwersja pokazuje, gdzie używasz konstrukcji specyficznych dla jednego producenta.

Po konwersji warto sformatować wynik, używając naszego formatera SQL. Jeśli chcesz schemat dla ORM-a, mamy konwerter SQL na ORM.

Pytania i odpowiedzi

Konwerter dialektów SQL

Po co konwerter dialektów SQL?

Jak korzystać

Do czego się przydaje

Pytania i odpowiedzi

Powiązane narzędzia

Formater SQL

Konwerter SQL na ORM

Konwerter DBML na SQL

Parser connection stringa do bazy

Konwerter dialektów SQL

Po co konwerter dialektów SQL?

Jak korzystać

Do czego się przydaje

Pytania i odpowiedzi

Powiązane narzędzia

Formater SQL

Konwerter SQL na ORM

Konwerter DBML na SQL

Parser connection stringa do bazy