Was bedeuten >, <, - in Refs?

Sie zeigen **Relations-Seiten**. ` ` = many-to-one, `-` = one-to-one. Beispiel: `Ref: posts.user_id > users.id` heißt "ein User hat viele Posts", und der Foreign Key lebt in der `posts`-Tabelle. Der Konverter versteht die Richtungen und emittet den FK auf der richtigen Seite.

Generiert es Foreign Keys mit ON DELETE CASCADE?

Nur **nackte FOREIGN KEY** ohne ON DELETE/UPDATE-Regeln. DBML unterstützt `[delete: cascade]` auf einem Ref, aber die Tool-Unterstützung ist inkonsistent. Der Output kriegt nacktes `REFERENCES table(column)`. Ergänze `ON DELETE CASCADE` von Hand, wo du es brauchst. Eine der Stellen, wo der Konverter bewusst nicht rät, um keine Production-Bugs einzuschleppen.

Warum nutzt MySQL-Output Backticks und PostgreSQL Double-Quotes?

Jede Engine hat eine andere Identifier-Quoting-Konvention. **MySQL**: ``Backticks``. **PostgreSQL und SQLite**: `"Double Quotes"`. **MSSQL** (hier nicht unterstützt): `[eckige Klammern]`. Der Konverter wählt den richtigen Stil, damit der Output as-is läuft.

Wie konvertiert es "integer [increment]"?

Abhängig vom Dialekt. **PostgreSQL**: `SERIAL` (oder `BIGSERIAL` für bigint). **MySQL**: `INT AUTO_INCREMENT`. **SQLite**: `INTEGER` (das per Default mit `PRIMARY KEY` auto-incrementiert). Klassische Übersetzungen. Bevorzugst du das neuere `GENERATED ALWAYS AS IDENTITY` in Postgres, tweak den Output nach dem Generieren.

Kann ich ein Schema (Table schema.users) nutzen?

Ja, der Parser erkennt ein Schema-Präfix in Tabellennamen. `Table public.users { ... }` erzeugt `CREATE TABLE "public"."users" ( ... )`. **MySQL** hat keine Schemas im klassischen Sinn (es nutzt "database"), aber der Output ist syntaktisch valide.

**PostgreSQL** kriegt ein natives `CREATE TYPE ... AS ENUM (...)`. **MySQL und SQLite** kriegen einen **Kommentar** mit den erlaubten Werten, weil die idiomatische Implementierung in diesen DBs `ENUM(...)` auf der Spalte (MySQL) oder `TEXT CHECK (col IN ...)` (SQLite) ist, was Wissen darüber verlangt, **welche Spalte** das Enum nutzt, und unser minimaler Parser bindet das nicht automatisch.

Warum sieht der Output nicht exakt wie dbdiagram.io-Export aus?

dbdiagram.io generiert SQL mit zusätzlichen Optionen und manchmal Extra-Sections (Kommentare, ALTER TABLE für FKs separat). Unser Konverter ist minimalistisch: CREATE TABLE + CREATE INDEX + ALTER TABLE für Out-of-Block-Refs, ohne Dekor. Der Output ist **syntaktisch kompatibel**, das Layout kann abweichen.

Was, wenn ich einen Parse-Fehler in DBML habe?

Der Konverter **versucht trotzdem SQL zu generieren** für das, was er versteht, und die **Fehler-Liste** erscheint drunter mit Zeilennummern. Häufigste Fehler: nicht geschlossene `[`-Klammer, Tippfehler in einem Typ, nicht geschlossener `{`-Block, kaputte Ref-Syntax. Fixen, dann sollte die Liste leer sein.

Gehen meine Daten an einen Server?

Nein. Der ganze Parser und SQL-Emitter läuft im Browser in JavaScript. DBML verlässt deinen Rechner nie.

DBML zu SQL - kostenlos

Dialekt

Ergebnis formatieren

DBML (Eingabe)3 Tabellen / 3 Refs

SQL (Ausgabe)

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");

Was ist DBML und warum es zu SQL konvertieren?

DBML (Database Markup Language) ist ein Format von Holistics, genutzt im populären dbdiagram.io. Es lässt dich ein DB-Schema in einer sauberen, kompakten Form beschreiben, ohne die volle syntaktische Zeremonie von SQL.

In DBML schreibst du `Table users { id integer [pk] name varchar }` statt `CREATE TABLE users (id INTEGER PRIMARY KEY, name VARCHAR(255))`. Kürzer, lesbarer, einfacher zu reviewen. Aber irgendwann brauchst du echtes SQL, um Tabellen in einer echten DB anzulegen.

Dieses Tool konvertiert DBML zu SQL für PostgreSQL, MySQL oder SQLite. Unterstützt: Tabellen, Spalten mit Typen, Primary Keys, Auto-Increment, NOT NULL, UNIQUE, Defaults, Indexes, Foreign Keys (Refs), Enums. Zeigt auch Parse-Fehler mit Zeilennummern.

So nutzt du das Tool

Dein DBML-Schema ins linke Panel pasten. Format folgt dbdiagram.io.

Ziel-Dialekt wählen: PostgreSQL, MySQL oder SQLite. Jeder hat eigene Typen und Konventionen.

Rechts kriegst du CREATE TABLE und ALTER TABLE fertig zum Pasten in eine Migration oder deine DB.

Gibt es Parse-Fehler, erscheint die Liste drunter mit Zeilennummern. Input fixen und der Output updated.

Ergebnis mit Copy-Button kopieren und in dein Migrations-Tool pasten: Prisma, Drizzle, Flyway, Liquibase, was auch immer.

Der Format result-Toggle schickt den Output durch einen SQL-Formatter für saubere Einrückung. Aus für Rohausgabe.

Wann das nützlich ist

Klassische Szenarien:

Neue DB von Null entwerfen. Du startest in DBML, weil es schneller Ideen festhält als volles SQL. Steht das Schema, generierst du CREATE TABLE.
Diagramm mit einer Migration syncen. Du hast ein Diagramm in dbdiagram.io (oder exportiert aus einem anderen Tool) und willst Tabellen in einer neuen DB anlegen. Der Konverter kürzt den Weg.
Technische Doku. DBML ist auch für Nicht-Engineers lesbar. SQL ist ausführbar. Einmal in DBML schreiben, SQL für Entwickler und Diagramm für den Produktmanager generieren.
Schema-Code-Review vor einer Migration. Einen Fehler in DBML zu sehen ist einfacher als in vielen CREATE-TABLE-Zeilen.
SQL lernen. Schau zu, wie aus einem simplen `Table users { id integer [pk] }` ein volles `CREATE TABLE "users" ("id" INTEGER PRIMARY KEY)` wird. Schöner Lernpfad.

Nach dem Generieren willst du das SQL vielleicht formatieren. Brauchst du ein ORM-Schema? Schau den SQL-zu-ORM-Konverter.

Fragen und Antworten

Tabellen mit beliebig vielen Spalten, Typen (integer, varchar(255), text, boolean, timestamp etc.), Spalten-Settings in eckigen Klammern: `pk`, `primary key`, `increment`, `not null`, `null`, `unique`, `default: ...`, `note: ...`, `ref: > table.column`. Indexes-Blöcke: Single- und Multi-Column-Indexes, `unique` und `name` Optionen. Refs außerhalb von Tabellen: `Ref: a.col > b.col`, `<`, `-`. Enum mit Werteliste. Kommentare `// line`. Schema in Tabellennamen wie `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");

Was ist DBML und warum es zu SQL konvertieren?

So nutzt du das Tool

Dein DBML-Schema ins linke Panel pasten. Format folgt dbdiagram.io.

Ziel-Dialekt wählen: PostgreSQL, MySQL oder SQLite. Jeder hat eigene Typen und Konventionen.

Rechts kriegst du CREATE TABLE und ALTER TABLE fertig zum Pasten in eine Migration oder deine DB.

Gibt es Parse-Fehler, erscheint die Liste drunter mit Zeilennummern. Input fixen und der Output updated.

Ergebnis mit Copy-Button kopieren und in dein Migrations-Tool pasten: Prisma, Drizzle, Flyway, Liquibase, was auch immer.

Der Format result-Toggle schickt den Output durch einen SQL-Formatter für saubere Einrückung. Aus für Rohausgabe.

Wann das nützlich ist

Klassische Szenarien:

Neue DB von Null entwerfen. Du startest in DBML, weil es schneller Ideen festhält als volles SQL. Steht das Schema, generierst du CREATE TABLE.
Diagramm mit einer Migration syncen. Du hast ein Diagramm in dbdiagram.io (oder exportiert aus einem anderen Tool) und willst Tabellen in einer neuen DB anlegen. Der Konverter kürzt den Weg.
Technische Doku. DBML ist auch für Nicht-Engineers lesbar. SQL ist ausführbar. Einmal in DBML schreiben, SQL für Entwickler und Diagramm für den Produktmanager generieren.
Schema-Code-Review vor einer Migration. Einen Fehler in DBML zu sehen ist einfacher als in vielen CREATE-TABLE-Zeilen.
SQL lernen. Schau zu, wie aus einem simplen `Table users { id integer [pk] }` ein volles `CREATE TABLE "users" ("id" INTEGER PRIMARY KEY)` wird. Schöner Lernpfad.

Nach dem Generieren willst du das SQL vielleicht formatieren. Brauchst du ein ORM-Schema? Schau den SQL-zu-ORM-Konverter.

Fragen und Antworten

DBML zu SQL

Was ist DBML und warum es zu SQL konvertieren?

So nutzt du das Tool

Wann das nützlich ist

Fragen und Antworten

Passende Tools

SQL-Formatter

SQL-Dialekt-Konverter

SQL zu ORM Konverter

DB Connection-String Parser

DBML zu SQL

Was ist DBML und warum es zu SQL konvertieren?

So nutzt du das Tool

Wann das nützlich ist

Fragen und Antworten

Passende Tools

SQL-Formatter

SQL-Dialekt-Konverter

SQL zu ORM Konverter

DB Connection-String Parser