Convertisseur SQL → JSON, gratuit

Convertissez des instructions SQL CREATE TABLE en schéma JSON. Extrayez instantanément les noms de colonnes, les types et les contraintes.

Vos données ne quittent jamais votre appareil

À propos de la conversion SQL → JSON

Cet outil analyse les instructions SQL CREATE TABLE et les convertit au format schéma JSON. Il extrait les noms de colonnes, les types de données (INT, VARCHAR, TEXT, BOOLEAN, DATE, TIMESTAMP, DECIMAL) et les contraintes (NOT NULL, PRIMARY KEY, valeurs DEFAULT). La sortie JSON convient à la documentation d'API, à la conception de bases de données ou aux outils de migration.

Types de données SQL pris en charge

Questions fréquentes

Quels dialectes SQL sont pris en charge ?

Ce convertisseur gère la syntaxe SQL standard utilisée par MySQL, PostgreSQL, SQL Server et SQLite. Les fonctionnalités spécifiques à un dialecte peuvent ne pas être entièrement reconnues.

Gère-t-il des contraintes complexes ?

Le convertisseur reconnaît NOT NULL, PRIMARY KEY, DEFAULT et les informations de type de base. Les contraintes complexes comme CHECK ou FOREIGN KEY sont stockées sous forme d'annotations texte.

Puis-je utiliser la sortie JSON directement ?

Oui ! La sortie JSON est formatée pour la lisibilité et peut être utilisée dans des schémas d'API, des interfaces TypeScript ou des générateurs de documentation.

Schéma, pas données : ce que fait cet outil

Ce convertisseur prend une instruction SQL CREATE TABLE et produit un schéma JSON : une description des colonnes, des types et des contraintes de base, adaptée aux contrats d'API, à la génération de types TypeScript et aux migrations vers les magasins de documents. Il ne convertit pas les lignes INSERT ni les jeux de résultats de requête en JSON. L'intérêt de recherche pour « SQL to JSON » se partage à peu près en deux entre ces deux besoins ; si vous êtes arrivé en espérant une conversion ligne-vers-objet, il vous faudra un autre outil. Le chemin de conversion de schéma est le cas orienté développeur : vous avez une définition de table et voulez une description structurée de sa forme qu'un autre outil peut consommer.

Une brève histoire de SQL

SQL a été conçu au laboratoire de recherche d'IBM à San Jose au début des années 1970 par Donald D. Chamberlin et Raymond F. Boyce. Le nom d'origine était SEQUEL : Structured English Query Language, conçu comme une interface de plus haut niveau pour la base de données relationnelle expérimentale System R d'IBM. Le modèle relationnel lui-même avait été publié en 1970 par Edgar F. Codd ; la contribution de Chamberlin et Boyce était une syntaxe que des analystes ordinaires pouvaient lire, calquée sur des clauses en anglais naturel (SELECT … FROM … WHERE …) plutôt que sur les symboles algébriques de Codd. Boyce (qui prêterait aussi son nom à la forme normale de Boyce-Codd) est mort en 1974 à l'âge de 26 ans, avant que le langage qu'il a co-inventé ne connaisse une sortie commerciale. Le nom a été changé en SQL en 1975 en raison d'un conflit de marque avec la marque SEQUEL de Hawker Siddeley, bien que la prononciation d'origine « sequel » persiste aux États-Unis aux côtés de l'internationale « ess-cue-ell ».

ANSI a normalisé SQL en 1986 (SQL-86), l'ISO a ratifié une version essentiellement identique en 1987 sous le nom d'ISO/IEC 9075, et la norme a été révisée tous les trois à cinq ans depuis : SQL-92 (toujours la base que supposent la plupart des tutoriels), SQL:1999 (requêtes récursives, déclencheurs), SQL:2003 (type XML, MERGE), SQL:2011 (tables temporelles), SQL:2016 (prise en charge de JSON) et plus récemment SQL:2023 (tableaux multidimensionnels, requêtes de graphes de propriétés). Malgré des vagues de technologies concurrentes (bases de données objet dans les années 1990, NoSQL à la fin des années 2000, lacs de données dans les années 2010), SQL a persisté comme le langage de requête dominant pour les données structurées pendant plus de cinquante ans. En 2024, même la plupart des plateformes NoSQL ont réintroduit SQL ou des couches de type SQL (le CQL de Cassandra, l'étape d'agrégation $sql de MongoDB, le PartiQL de DynamoDB, Spark SQL, Trino, DuckDB, BigQuery, Snowflake), confirmant la prédiction de Mike Stonebraker selon laquelle le langage survivrait à tout moteur de stockage unique.

JSON en un paragraphe

JSON (JavaScript Object Notation) a été spécifié par Douglas Crockford en 2001, dérivé d'un sous-ensemble de la syntaxe des littéraux d'objet JavaScript, et normalisé sous le nom d'ECMA-404 en 2013 et d'IETF RFC 8259 en 2017. Il ne possède que six types de valeurs (chaîne, nombre, booléen, null, tableau, objet) et aucun concept natif de dates, de décimaux, de binaire ou de schémas. Le schéma JSON (une spécification distincte, actuellement au brouillon 2020-12) y superpose une validation de structure et de type. L'intérêt du schéma JSON pour ce convertisseur : c'est un format portable et indépendant du schéma que presque tous les générateurs de code et bibliothèques de validation modernes comprennent.

La conversion mécanique

Une entrée représentative :

CREATE TABLE users (
  id INT PRIMARY KEY,
  email VARCHAR(255) NOT NULL,
  signup_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  is_active BOOLEAN DEFAULT TRUE
);

Correspond à :

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "users",
  "type": "object",
  "properties": {
    "id": { "type": "integer" },
    "email": { "type": "string", "maxLength": 255 },
    "signup_at": { "type": "string", "format": "date-time" },
    "is_active": { "type": "boolean", "default": true }
  },
  "required": ["id", "email"]
}

Étape par étape : tokeniser l'entrée, repérer CREATE TABLE et le nom de la table, trouver la liste de colonnes entre parenthèses, découper les définitions de colonnes sur les virgules de premier niveau (en respectant les parenthèses imbriquées pour des choses comme DECIMAL(10,2) ou CHECK (x > 0)), analyser chaque colonne en nom + type + modificateurs, et faire correspondre le type SQL au type de schéma JSON le plus proche. NOT NULL devient l'appartenance au tableau required. DEFAULT devient une valeur default. PRIMARY KEY devient généralement une annotation ou une appartenance à required. CHECK, FOREIGN KEY, UNIQUE et les index deviennent généralement des annotations textuelles parce que le schéma JSON n'a pas d'équivalent direct.

Le problème des dialectes

SQL est notoirement une famille de dialectes, pas un langage unique. Même la mise entre guillemets de base des identifiants diffère :

Les noms de types divergent aussi. INT(11) dans MySQL est une indication de largeur d'affichage que PostgreSQL rejette. SERIAL dans PostgreSQL est un raccourci pour INT NOT NULL AUTO_INCREMENT PRIMARY KEY ; IDENTITY remplit le même rôle dans SQL Server ; SQLite utilise AUTOINCREMENT. BOOLEAN est en réalité TINYINT(1) sous le capot dans MySQL. Les types géographiques (GEOMETRY, POINT), les types de colonnes JSON (JSON, JSONB), les types tableaux (INTEGER[] de PostgreSQL) et les types vecteurs plein texte (VECTOR(1536) dans pgvector) n'ont pas d'équivalent en schéma JSON et finissent en annotations textuelles opaques. Les données binaires BLOB et BYTEA n'ont pas de représentation JSON native ; la pratique standard est la transformation en chaîne base64 avec une indication contentEncoding.

Types SQL contre types JSON, le décalage d'impédance

SQL a un système de types riche ; JSON a six types de valeurs et aucun schéma. Bon à savoir :

Quand recourir à cet outil

Alternatives modernes

Plus de questions

Et si mon CREATE TABLE a des contraintes FOREIGN KEY ?

Le schéma JSON n'a pas de concept natif de clé étrangère. La représentation la plus propre est une annotation personnalisée (p. ex. une propriété non standard x-foreign-key) notant la table et la colonne référencées. Ce convertisseur préserve la relation sous forme de note textuelle dans la sortie ; si vous avez besoin d'une modélisation de référence totalement formelle, le $ref du schéma JSON + un bloc de définitions séparé est ce qui s'en rapproche le plus, mais c'est peu commode pour les cas plusieurs-à-plusieurs. Pour une modélisation relationnelle plus riche, envisagez DBML ou Atlas HCL.

Pourquoi la sortie n'inclut-elle pas les contraintes CHECK ?

Le schéma JSON peut exprimer de nombreuses contraintes CHECK simples : CHECK (age >= 0) devient {"minimum": 0}, CHECK (status IN ('a','b')) devient {"enum": ["a","b"]} ; mais les expressions SQL arbitraires dans les clauses CHECK (appels de fonction, jointures, sous-requêtes) n'ont pas d'équivalent en schéma JSON. Le convertisseur reconnaît les cas simples et préserve les contraintes complexes sous forme d'annotations textuelles plutôt que de les supprimer silencieusement.

Puis-je convertir des lignes INSERT en JSON ?

Pas avec cet outil : il ne gère que la conversion au niveau du schéma (CREATE TABLE). Pour la conversion au niveau des lignes, la bonne approche est généralement native à la base de données : le SELECT row_to_json(t) FROM tbl t de PostgreSQL, le JSON_OBJECT() de MySQL, ou l'export en CSV suivi d'un outil CSV-vers-JSON. Le mysqldump --xml redirigé via un convertisseur XML-vers-JSON est un autre chemin bien balisé.

Pourquoi BIGINT pose-t-il problème en JSON ?

Le JSON.parse de JavaScript utilise des doubles IEEE 754, qui ne peuvent représenter exactement que les entiers jusqu'à 2^53 = 9 007 199 254 740 992. Les nombres au-delà perdent en précision. Le BIGINT de SQL va jusqu'à 2^63 ≈ 9,2 trillions, bien au-delà de la plage d'entiers JSON sûre. La convention multiplateforme pour transporter sûrement un BIGINT via JSON est de le sérialiser comme une chaîne et de l'analyser avec BigInt à destination ; de nombreuses API (les identifiants de tweets de Twitter / X, les identifiants Stripe, le bigserial de PostgreSQL) font exactement cela.

Quelque chose est-il envoyé à un serveur ?

Non. L'analyseur s'exécute dans votre navigateur ; la sortie JSON est construite localement. Le SQL collé ne quitte jamais votre appareil, ce qui compte si vos instructions CREATE TABLE contiennent des noms de colonnes propriétaires, des conventions de tables internes ou d'autres détails que vous ne voulez pas voir journalisés. La page fonctionne hors ligne une fois chargée.

Outils associés

Formateur JSON

Formatez, minifiez et validez du JSON instantanément.

Formateur SQL

Formatez et embellissez les requêtes SQL.

Formateur XML

Formatez et validez les documents XML.