Que signifient >, <, - dans les refs ?

Ils indiquent les **côtés de la relation**. ` ` = many-to-one, `-` = one-to-one. Exemple : `Ref: posts.user_id > users.id` signifie « un utilisateur a plusieurs posts » et la foreign key vit dans la table `posts`. Le convertisseur comprend ces directions et émet la FK du bon côté.

Génère-t-il des foreign keys avec ON DELETE CASCADE ?

Seulement des **FOREIGN KEY simples** sans règles ON DELETE/UPDATE. DBML prend en charge `[delete: cascade]` sur une ref, mais le support outil est inégal. La sortie reçoit un `REFERENCES table(column)` nu. Ajoutez `ON DELETE CASCADE` à la main là où vous en avez besoin. C'est un des endroits où le convertisseur refuse délibérément de deviner, pour éviter d'introduire un bug en production.

Pourquoi la sortie MySQL utilise des backticks et PostgreSQL des guillemets doubles ?

Chaque moteur a sa propre convention de quoting des identifiants. **MySQL** : ``backticks``. **PostgreSQL et SQLite** : `"guillemets doubles"`. **MSSQL** (non pris en charge ici) : `[crochets]`. Le convertisseur choisit le bon style pour que la sortie fonctionne telle quelle.

Comment convertit-il « integer [increment] » ?

Dépend du dialecte. **PostgreSQL** : `SERIAL` (ou `BIGSERIAL` pour bigint). **MySQL** : `INT AUTO_INCREMENT`. **SQLite** : `INTEGER` (qui s'auto-incrémente par défaut avec `PRIMARY KEY`). Ce sont les traductions classiques. Si vous préférez le plus récent `GENERATED ALWAYS AS IDENTITY` en Postgres, ajustez la sortie après génération.

Puis-je utiliser un schema (Table schema.users) ?

Oui, le parser reconnaît un préfixe de schema dans les noms de table. `Table public.users { ... }` produit `CREATE TABLE "public"."users" ( ... )`. **MySQL** n'a pas de schemas au sens classique (il utilise « database » à la place), mais la sortie est syntaxiquement valide.

**PostgreSQL** reçoit un `CREATE TYPE ... AS ENUM (...)` natif. **MySQL et SQLite** reçoivent un **commentaire** avec les valeurs autorisées, parce que l'implémentation idiomatique dans ces bases est `ENUM(...)` sur la colonne (MySQL) ou `TEXT CHECK (col IN ...)` (SQLite), ce qui exige de savoir **quelle colonne** utilise l'enum, et notre parser minimal ne lie pas ça automatiquement.

Pourquoi la sortie ne ressemble-t-elle pas exactement à l'export dbdiagram.io ?

dbdiagram.io génère du SQL avec des options supplémentaires et parfois des sections supplémentaires (commentaires, ALTER TABLE pour les FK séparément). Notre convertisseur est minimaliste : CREATE TABLE + CREATE INDEX + ALTER TABLE pour les refs hors bloc, sans décoration. La sortie est **syntaxiquement compatible**, même si la mise en page peut différer.

Que se passe-t-il en cas d'erreur de parsing DBML ?

Le convertisseur **tente quand même de générer du SQL** pour ce qu'il comprend, et la **liste d'erreurs** apparaît en dessous avec les numéros de ligne. Erreurs les plus courantes : crochet `[` non fermé, faute de frappe dans un type, bloc `{` non fermé, syntaxe de ref mal formée. Corrigez-les et la liste d'erreurs devrait se vider.

Mes données partent-elles vers un serveur ?

Non. Tout le parser et l'émetteur SQL tournent dans votre navigateur en JavaScript. Le DBML ne quitte jamais votre machine.

DBML vers SQL - gratuit

Dialecte

Formater le résultat

DBML (entrée)3 tables / 3 refs

SQL (sortie)

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

Qu'est-ce que DBML et pourquoi le convertir en SQL ?

DBML (Database Markup Language) est un format de Holistics, utilisé dans le populaire outil dbdiagram.io. Il permet de décrire un schéma de base sous une forme propre et compacte, sans tout le cérémonial syntaxique du SQL.

En DBML, vous écrivez `Table users { id integer [pk] name varchar }` au lieu de `CREATE TABLE users (id INTEGER PRIMARY KEY, name VARCHAR(255))`. Plus court, plus lisible, plus facile à relire. Mais il faut bien du vrai SQL pour créer les tables dans une vraie base.

Cet outil convertit DBML en SQL pour PostgreSQL, MySQL ou SQLite. Pris en charge : tables, colonnes typées, clés primaires, auto-increment, NOT NULL, UNIQUE, valeurs par défaut, index, foreign keys (Refs), enums. Affiche aussi les erreurs de parsing avec numéros de ligne.

Mode d'emploi

Collez votre schéma DBML dans le panneau de gauche. Le format suit dbdiagram.io.

Choisissez le dialecte cible : PostgreSQL, MySQL ou SQLite. Chacun a ses propres types et conventions.

À droite, vous obtenez les CREATE TABLE et ALTER TABLE prêts à coller dans une migration ou dans votre base.

En cas d'erreurs de parsing, la liste apparaît en dessous avec les numéros de ligne. Corrigez l'entrée et la sortie se met à jour.

Copiez le résultat avec le bouton Copier et collez-le dans votre outil de migration, Prisma, Drizzle, Flyway, Liquibase, ou ce que vous utilisez.

L'option Format result passe la sortie dans un formateur SQL pour une indentation propre. Désactivez-la pour une sortie brute.

Quand c'est utile

Scénarios courants :

Conception d'une nouvelle base de zéro. Vous commencez en DBML parce qu'il est plus rapide de capturer des idées qu'en SQL complet. Une fois le schéma stabilisé, vous générez les CREATE TABLE.
Synchronisation d'un diagramme avec une migration. Vous avez un diagramme dans dbdiagram.io (ou exporté depuis un autre outil) et vous voulez créer les tables dans une nouvelle base. Le convertisseur raccourcit ce chemin.
Documentation technique. DBML est lisible par les non-ingénieurs. SQL est exécutable. Écrivez une fois en DBML, générez du SQL pour les développeurs et un diagramme pour la PM.
Revue de code de schéma avant une migration. Plus facile de repérer une erreur en DBML que dans plusieurs lignes de CREATE TABLE.
Apprendre SQL. Observez comment un simple `Table users { id integer [pk] }` se déploie en `CREATE TABLE "users" ("id" INTEGER PRIMARY KEY)`. Un beau chemin d'apprentissage.

Après avoir généré le SQL, vous voudrez peut-être le formater. Besoin d'un schéma ORM à la place ? Voir le convertisseur SQL vers ORM.

Questions et réponses

Tables avec un nombre quelconque de colonnes, types (integer, varchar(255), text, boolean, timestamp, etc.), paramètres de colonnes entre crochets : `pk`, `primary key`, `increment`, `not null`, `null`, `unique`, `default: ...`, `note: ...`, `ref: > table.column`. Blocs Indexes : index simples et multi-colonnes, options `unique` et `name`. Refs hors tables : `Ref: a.col > b.col`, `<`, `-`. Enum avec liste de valeurs. Commentaires `// ligne`. Schema dans les noms de table comme `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");

Qu'est-ce que DBML et pourquoi le convertir en SQL ?

Mode d'emploi

Collez votre schéma DBML dans le panneau de gauche. Le format suit dbdiagram.io.

Choisissez le dialecte cible : PostgreSQL, MySQL ou SQLite. Chacun a ses propres types et conventions.

À droite, vous obtenez les CREATE TABLE et ALTER TABLE prêts à coller dans une migration ou dans votre base.

En cas d'erreurs de parsing, la liste apparaît en dessous avec les numéros de ligne. Corrigez l'entrée et la sortie se met à jour.

Copiez le résultat avec le bouton Copier et collez-le dans votre outil de migration, Prisma, Drizzle, Flyway, Liquibase, ou ce que vous utilisez.

L'option Format result passe la sortie dans un formateur SQL pour une indentation propre. Désactivez-la pour une sortie brute.

Quand c'est utile

Scénarios courants :

Conception d'une nouvelle base de zéro. Vous commencez en DBML parce qu'il est plus rapide de capturer des idées qu'en SQL complet. Une fois le schéma stabilisé, vous générez les CREATE TABLE.
Synchronisation d'un diagramme avec une migration. Vous avez un diagramme dans dbdiagram.io (ou exporté depuis un autre outil) et vous voulez créer les tables dans une nouvelle base. Le convertisseur raccourcit ce chemin.
Documentation technique. DBML est lisible par les non-ingénieurs. SQL est exécutable. Écrivez une fois en DBML, générez du SQL pour les développeurs et un diagramme pour la PM.
Revue de code de schéma avant une migration. Plus facile de repérer une erreur en DBML que dans plusieurs lignes de CREATE TABLE.
Apprendre SQL. Observez comment un simple `Table users { id integer [pk] }` se déploie en `CREATE TABLE "users" ("id" INTEGER PRIMARY KEY)`. Un beau chemin d'apprentissage.

Après avoir généré le SQL, vous voudrez peut-être le formater. Besoin d'un schéma ORM à la place ? Voir le convertisseur SQL vers ORM.

Questions et réponses

DBML vers SQL

Qu'est-ce que DBML et pourquoi le convertir en SQL ?

Mode d'emploi

Quand c'est utile

Questions et réponses

Outils similaires

Formateur SQL

Convertisseur dialectes SQL

SQL vers ORM

Parseur connection string DB

DBML vers SQL

Qu'est-ce que DBML et pourquoi le convertir en SQL ?

Mode d'emploi

Quand c'est utile

Questions et réponses

Outils similaires

Formateur SQL

Convertisseur dialectes SQL

SQL vers ORM

Parseur connection string DB