Comment les types de colonnes sont-ils déduits du JSON ?

Chaque valeur de la colonne vote : les entiers donnent INTEGER (BIGINT au-delà de 32 bits), tout décimal impose DOUBLE PRECISION, true/false donnent BOOLEAN, les chaînes datées ISO donnent TIMESTAMP, et tout conflit finit en TEXT. Toutes les lignes sont examinées.

Que change-t-il entre les dialectes SQL ?

Les guillemets d’identifiants (doubles, accents graves, crochets), l’orthographe des types (BOOLEAN contre TINYINT(1) contre BIT), les littéraux booléens (TRUE contre 1) et le préfixe N que SQL Server veut sur le texte Unicode.

Que deviennent les objets aux clés différentes ?

Les colonnes sont l’union des clés de toutes les lignes, dans l’ordre d’apparition ; les lignes sans une clé y insèrent NULL. C’est ainsi que les données hétérogènes d’API doivent en général atterrir en table.

Le script généré est-il prêt pour la production ?

Il est prêt à importer : guillemets sûrs et types sensés. Une table de production mérite encore clé primaire, NOT NULL et index — qu’aucune déduction ne peut deviner des données.

JSON vers SQL

Transformez un tableau JSON en CREATE TABLE aux types déduits et en INSERT groupés — pour PostgreSQL, MySQL, SQLite ou SQL Server.

JSON vers SQL fonctionne entièrement dans votre navigateur. Vos données sont converties sur votre appareil et jamais envoyées.

Ouvrir le convertisseur CSV vers SQL

À propos de JSON vers SQL

JSON vers SQL prend un tableau d’objets — réponse d’API, export, fichier de test — et produit les deux instructions qui l’amènent en base : un CREATE TABLE dont les types de colonnes sont déduits de toutes les valeurs de chaque colonne, et des INSERT regroupés en listes VALUES multi-lignes. La déduction est faite proprement : les entiers au-delà de 32 bits deviennent BIGINT, les chaînes au format ISO deviennent TIMESTAMP, les colonnes mixtes se replient sûrement sur TEXT, et chaque type canonique s’écrit dans l’orthographe du dialecte — BOOLEAN arrive en TINYINT(1) chez MySQL et en BIT chez SQL Server. Les détails qui cassent les scripts manuels sont précisément la cible : identifiants entre guillemets par dialecte pour qu’une colonne order ne heurte jamais le mot-clé, apostrophes doublées pour qu’O’Brien survive, clés absentes en NULL et objets imbriqués sérialisés en texte JSON.

Fonctionnalités

CREATE TABLE aux types déduits de toutes les lignes
INSERT multi-lignes à taille de lot réglable
Dialectes PostgreSQL, MySQL, SQLite et SQL Server
Identifiants entre guillemets — mots réservés sans danger
Échappement des valeurs : apostrophes doublées, NULL explicites
Clés absentes en NULL ; imbriqué en texte JSON

Comment utiliser JSON vers SQL

Collez un tableau JSON d’objets
Nommez la table et choisissez le dialecte
Ajustez les lignes par INSERT au besoin
Copiez le SQL — les types s’affichent d’abord pour relecture

Exemple

Entrée

[{"id":1,"name":"O'Brien","active":true}]

Sortie

CREATE TABLE "users" ("id" INTEGER, "name" TEXT, "active" BOOLEAN);
INSERT INTO "users" ("id", "name", "active") VALUES (1, 'O''Brien', TRUE);

L’apostrophe doublée d’O’’Brien est ce qui garde le script valide.

Erreurs courantes et dépannage

Une colonne numérique est sortie en TEXT. — Une valeur de cette colonne est une chaîne — "42" entre guillemets, une chaîne vide ou un N/A. La déduction parcourt toutes les lignes et se replie sur TEXT au moindre conflit.
Le script échoue sur une colonne nommée order ou user. — Il ne devrait pas — les identifiants sont mis entre guillemets par dialecte exactement pour cela. Sinon, vérifiez que le dialecte correspond à la base : accents graves pour MySQL, crochets pour SQL Server.
Les dates ont été importées en texte brut. — Seules les formes ISO 8601 (2024-01-15, heure facultative) se déduisent en TIMESTAMP. Les formats locaux comme 15/01/2024 sont ambigus et restent TEXT à dessein.

Foire aux questions

Comment les types de colonnes sont-ils déduits du JSON ?: Chaque valeur de la colonne vote : les entiers donnent INTEGER (BIGINT au-delà de 32 bits), tout décimal impose DOUBLE PRECISION, true/false donnent BOOLEAN, les chaînes datées ISO donnent TIMESTAMP, et tout conflit finit en TEXT. Toutes les lignes sont examinées.
Que change-t-il entre les dialectes SQL ?: Les guillemets d’identifiants (doubles, accents graves, crochets), l’orthographe des types (BOOLEAN contre TINYINT(1) contre BIT), les littéraux booléens (TRUE contre 1) et le préfixe N que SQL Server veut sur le texte Unicode.
Que deviennent les objets aux clés différentes ?: Les colonnes sont l’union des clés de toutes les lignes, dans l’ordre d’apparition ; les lignes sans une clé y insèrent NULL. C’est ainsi que les données hétérogènes d’API doivent en général atterrir en table.
Le script généré est-il prêt pour la production ?: Il est prêt à importer : guillemets sûrs et types sensés. Une table de production mérite encore clé primaire, NOT NULL et index — qu’aucune déduction ne peut deviner des données.

Outils associés

CSV vers SQL — Génère des INSERT et un CREATE TABLE pour MySQL, PostgreSQL, SQLite et SQL Server, localement.
JSON vers CSV — Convertit un tableau d’objets JSON plats en CSV.
Formateur JSON — Embellit, minifie et valide le JSON avec la localisation des erreurs.
JSON vers TypeScript — Génère des interfaces TypeScript à partir d’un échantillon JSON.
JSON Flatten / Unflatten — Aplatissez du JSON imbriqué en clés à notation pointée, ou reconstruisez-le.
Trier les clés JSON — Classe récursivement les clés d’objet A→Z ou Z→A sans toucher aux tableaux.