Co znaczą znaki >, <, - w refach?

To **strony relacji**. ` ` = many-to-one (wielu do jednego), `-` = one-to-one (jeden do jednego). Przykład: `Ref: posts.user_id > users.id` znaczy "jeden user ma wiele postów", a klucz obcy (FOREIGN KEY) jest w tabeli `posts`. Konwerter rozumie te kierunki i generuje FK po właściwej stronie.

Czy generuje klucze obce z ON DELETE CASCADE?

Tylko **podstawowe FOREIGN KEY** bez ON DELETE/UPDATE rules. DBML pozwala dodać `[delete: cascade]` przy refie, ale wsparcie tej opcji jest niespójne. Wynik dostaje gołe `REFERENCES tabela(kolumna)`. Dodaj `ON DELETE CASCADE` ręcznie tam, gdzie potrzebujesz. To jedna z rzeczy, w których nasz konwerter celowo nie zgaduje, żeby nie wprowadzić bug-a w produkcji.

Czemu wynik dla MySQL ma backticki, a dla PostgreSQL podwójne cudzysłowy?

Każdy silnik używa innej konwencji do cudzysłowienia identyfikatorów. **MySQL**: ``backticki``. **PostgreSQL i SQLite**: `"podwójne cudzysłowy"`. **MSSQL** (nie obsługujemy): `[nawiasy kwadratowe]`. Konwerter dobiera prawidłowy styl, więc wynik jest gotowy bez modyfikacji.

Jak konwertuje typ "integer [increment]"?

Zależnie od dialektu. **PostgreSQL**: `SERIAL` (albo `BIGSERIAL` dla bigint). **MySQL**: `INT AUTO_INCREMENT`. **SQLite**: `INTEGER` (które domyślnie jest auto-inkrementowane przy `PRIMARY KEY`). To są klasyczne tłumaczenia, ale jeśli wolisz nowsze `GENERATED ALWAYS AS IDENTITY` w Postgresie, zmodyfikuj po wygenerowaniu.

Czy mogę użyć schematu (Table schema.users)?

Tak, parser rozpoznaje schemat w nazwie tabeli. `Table public.users { ... }` wygeneruje `CREATE TABLE "public"."users" ( ... )`. **MySQL** nie ma schematów w klasycznym sensie (używa "database" zamiast "schema"), ale wynik będzie składniowo poprawny.

**PostgreSQL** dostaje natywny `CREATE TYPE ... AS ENUM (...)`. **MySQL i SQLite** dostają **komentarz** z listą dozwolonych wartości, ponieważ idiomatyczna implementacja w tych bazach to `ENUM(...)` przy kolumnie (MySQL) albo `TEXT CHECK (col IN ...)` (SQLite), wymagająca info o tym, **która kolumna** używa enum-a, którą nasz prosty parser nie wiąże automatycznie.

Czemu wynik nie wygląda dokładnie jak z dbdiagram.io?

dbdiagram.io generuje SQL z dodatkowymi opcjami i czasem dodatkowymi sekcjami (komentarzami, ALTER TABLE z FK osobno). Nasz konwerter jest minimalistyczny: emituje CREATE TABLE + CREATE INDEX + ALTER TABLE dla refów out-of-block, bez zbędnego ozdabiania. Wynik jest **kompatybilny składniowo**, choć ułożenie może się różnić.

Co jeśli mam błąd parsowania w DBML?

Konwerter **dalej spróbuje wygenerować SQL** dla tego, co rozumie, a **lista błędów** pojawi się pod spodem z numerami linii. Najczęstsze błędy: niedomknięty nawias `[`, literówka w typie, niezamknięty blok `{`, błędna składnia ref-a. Popraw, sprawdź czy lista błędów zniknęła.

Czy moje dane gdzieś idą na serwer?

Nie. Cały parser i emiter SQL działa w przeglądarce w JavaScripcie. DBML nie wychodzi z Twojej maszyny.

Konwerter DBML na SQL - darmowy

Dialekt

Formatuj wynik

DBML (wejście)3 tabel / 3 refów

SQL (wynik)

CREATE TYPE "post_status" AS ENUM('draft', 'published', 'archived');

CREATE TABLE "users" (
  "id" SERIAL PRIMARY KEY,
  "email" VARCHAR(255) NOT NULL UNIQUE,
  "name" VARCHAR(100) NOT NULL,
  "is_active" BOOLEAN NOT NULL DEFAULT TRUE,
  "created_at" TIMESTAMP NOT NULL DEFAULT now()
);

CREATE TABLE "posts" (
  "id" SERIAL PRIMARY KEY,
  "user_id" INTEGER NOT NULL,
  "title" VARCHAR(200) NOT NULL,
  "body" TEXT,
  "published_at" TIMESTAMP,
  FOREIGN KEY ("user_id") REFERENCES "users" ("id")
);

CREATE TABLE "comments" (
  "id" SERIAL PRIMARY KEY,
  "post_id" INTEGER NOT NULL,
  "user_id" INTEGER NOT NULL,
  "body" TEXT NOT NULL,
  "created_at" TIMESTAMP NOT NULL DEFAULT now(),
  FOREIGN KEY ("post_id") REFERENCES "posts" ("id"),
  FOREIGN KEY ("user_id") REFERENCES "users" ("id")
);

CREATE UNIQUE INDEX "users_email_idx" ON "users" ("email");

CREATE INDEX "posts_user_id_published_at_idx" ON "posts" ("user_id", "published_at");

Co to jest DBML i po co konwertować na SQL?

DBML (Database Markup Language) to format opracowany przez Holistics, używany w popularnym narzędziu dbdiagram.io. Pozwala opisać schemat bazy danych w czytelnej, kompaktowej formie, bez całej składniowej ceremonii SQL-a.

W DBML piszesz `Table users { id integer [pk] name varchar }` zamiast `CREATE TABLE users (id INTEGER PRIMARY KEY, name VARCHAR(255))`. Krócej, czytelniej, łatwiej w code review. Ale ostatecznie potrzebujesz SQL-a, żeby utworzyć tabele w prawdziwej bazie.

To narzędzie konwertuje DBML na SQL dla PostgreSQL, MySQL albo SQLite. Obsługuje: tabele, kolumny z typami, klucze główne, auto-inkrementację, NOT NULL, UNIQUE, defaulty, indeksy, klucze obce (Ref-y), enumy. Pokazuje też błędy parsowania z numerami linii.

Jak korzystać

Wklej swój schemat w DBML w lewe pole. Format wzorowany na dbdiagram.io.

Wybierz dialekt docelowy: PostgreSQL, MySQL albo SQLite. Każdy ma własne typy i konwencje.

W prawym polu zobaczysz CREATE TABLE i ALTER TABLE gotowe do wklejenia do migracji albo do bazy.

Jeśli są błędy parsowania, lista pojawi się pod spodem z numerami linii. Popraw w wejściu i wynik się odświeży.

Skopiuj wynik przyciskiem Kopiuj i wklej do swojego migration tool-a, Prisma, Drizzle, Flyway, Liquibase, cokolwiek używasz.

Tryb Formatuj wynik używa formatera SQL żeby ładnie wciągnąć wcięcia. Możesz wyłączyć, jeśli wolisz surową formę.

Do czego się przydaje

Typowe scenariusze:

Projektowanie nowej bazy danych na białej kartce. Zaczynasz od DBML, bo szybciej zapisujesz pomysły, niż w pełnym SQL-u. Kiedy schemat dojrzeje, generujesz CREATE TABLE.
Synchronizacja diagramu z migracją. Masz diagram w dbdiagram.io (albo eksport z innego narzędzia), chcesz utworzyć tabele w nowej bazie. Konwerter przyspiesza tę drogę.
Dokumentacja techniczna. DBML jest czytelne dla nieprogramistów. SQL jest wykonywalny. Pisz raz w DBML, generuj SQL dla developerów i diagram dla product managera.
Code review schematu przed migracją. Łatwiej zobaczyć błąd w DBML niż w wielu liniach CREATE TABLE.
Nauka SQL-a. Patrz, jak proste `Table users { id integer [pk] }` rozwija się do pełnego `CREATE TABLE "users" ("id" INTEGER PRIMARY KEY)`. Dobra ścieżka edukacyjna.

Po wygenerowaniu SQL-a warto go sformatować. Jeśli potrzebujesz schemat dla ORM-a, mamy konwerter SQL na ORM.

Pytania i odpowiedzi

Tabele z dowolną liczbą kolumn, typy (integer, varchar(255), text, boolean, timestamp itp.), ustawienia kolumn w nawiasach kwadratowych: `pk`, `primary key`, `increment`, `not null`, `null`, `unique`, `default: ...`, `note: ...`, `ref: > tabela.kolumna`. Bloki Indexes: kolumny pojedyncze i wielokolumnowe, opcja `unique` i `name`. Ref poza tabelą: `Ref: a.col > b.col`, `<`, `-`. Enum z listą wartości. Komentarze `// linia`. Schemat w nazwie tabeli typu `public.users`.

CREATE TYPE "post_status" AS ENUM('draft', 'published', 'archived'); CREATE TABLE "users" ( "id" SERIAL PRIMARY KEY, "email" VARCHAR(255) NOT NULL UNIQUE, "name" VARCHAR(100) NOT NULL, "is_active" BOOLEAN NOT NULL DEFAULT TRUE, "created_at" TIMESTAMP NOT NULL DEFAULT now() ); CREATE TABLE "posts" ( "id" SERIAL PRIMARY KEY, "user_id" INTEGER NOT NULL, "title" VARCHAR(200) NOT NULL, "body" TEXT, "published_at" TIMESTAMP, FOREIGN KEY ("user_id") REFERENCES "users" ("id") ); CREATE TABLE "comments" ( "id" SERIAL PRIMARY KEY, "post_id" INTEGER NOT NULL, "user_id" INTEGER NOT NULL, "body" TEXT NOT NULL, "created_at" TIMESTAMP NOT NULL DEFAULT now(), FOREIGN KEY ("post_id") REFERENCES "posts" ("id"), FOREIGN KEY ("user_id") REFERENCES "users" ("id") ); CREATE UNIQUE INDEX "users_email_idx" ON "users" ("email"); CREATE INDEX "posts_user_id_published_at_idx" ON "posts" ("user_id", "published_at");

Co to jest DBML i po co konwertować na SQL?

Jak korzystać

Wklej swój schemat w DBML w lewe pole. Format wzorowany na dbdiagram.io.

Wybierz dialekt docelowy: PostgreSQL, MySQL albo SQLite. Każdy ma własne typy i konwencje.

W prawym polu zobaczysz CREATE TABLE i ALTER TABLE gotowe do wklejenia do migracji albo do bazy.

Jeśli są błędy parsowania, lista pojawi się pod spodem z numerami linii. Popraw w wejściu i wynik się odświeży.

Skopiuj wynik przyciskiem Kopiuj i wklej do swojego migration tool-a, Prisma, Drizzle, Flyway, Liquibase, cokolwiek używasz.

Tryb Formatuj wynik używa formatera SQL żeby ładnie wciągnąć wcięcia. Możesz wyłączyć, jeśli wolisz surową formę.

Do czego się przydaje

Typowe scenariusze:

Projektowanie nowej bazy danych na białej kartce. Zaczynasz od DBML, bo szybciej zapisujesz pomysły, niż w pełnym SQL-u. Kiedy schemat dojrzeje, generujesz CREATE TABLE.
Synchronizacja diagramu z migracją. Masz diagram w dbdiagram.io (albo eksport z innego narzędzia), chcesz utworzyć tabele w nowej bazie. Konwerter przyspiesza tę drogę.
Dokumentacja techniczna. DBML jest czytelne dla nieprogramistów. SQL jest wykonywalny. Pisz raz w DBML, generuj SQL dla developerów i diagram dla product managera.
Code review schematu przed migracją. Łatwiej zobaczyć błąd w DBML niż w wielu liniach CREATE TABLE.
Nauka SQL-a. Patrz, jak proste `Table users { id integer [pk] }` rozwija się do pełnego `CREATE TABLE "users" ("id" INTEGER PRIMARY KEY)`. Dobra ścieżka edukacyjna.

Po wygenerowaniu SQL-a warto go sformatować. Jeśli potrzebujesz schemat dla ORM-a, mamy konwerter SQL na ORM.

Pytania i odpowiedzi

Konwerter DBML na SQL

Co to jest DBML i po co konwertować na SQL?

Jak korzystać

Do czego się przydaje

Pytania i odpowiedzi

Powiązane narzędzia

Formater SQL

Konwerter dialektów SQL

Konwerter SQL na ORM

Parser connection stringa do bazy

Konwerter DBML na SQL

Co to jest DBML i po co konwertować na SQL?

Jak korzystać

Do czego się przydaje

Pytania i odpowiedzi

Powiązane narzędzia

Formater SQL

Konwerter dialektów SQL

Konwerter SQL na ORM

Parser connection stringa do bazy