La plupart des JSON que je traite commencent leur vie comme une réponse API et doivent finir dans une base de données Sur le backend Toolz.dev, qui fonctionne sur Express et TypeORM sur PostgreSQL, j'ai perdu le compte des fois où j'ai EU une exportation JSON d'un service que je voulais charger dans une table pour une requête rapide, une graine de migration, ou une reproduction locale d'un bug Le faire à la main est sinistre : vous écrivez un CREATE TABLE, puis vous tapez à la main INSERT déclarations, citant chaque chaîne, doublant chaque apostrophe, se rappelant quels champs sont des nombres et transformant les clés manquantes en NULL. Se tromper sur une rangée sur deux cents et tout le lot ne fonctionne pas.
Un convertisseur JSON vers SQL fait ce travail mécanique pour vous Vous collez un tableau d'objets, choisissez un dialecte de base de données et il produit un CREATE TABLE avec des types de colonnes sensibles plus le INSERT instructions pour charger chaque ligne Ce guide explique comment fonctionne la conversion, les décisions qu'elle prend sur les types et les citations, et les situations réelles où elle permet d'économiser un après-midi.
tl;dr : le Convertisseur JSON vers SQL transforme un tableau d'objets JSON en
CREATE TABLEetINSERTinstructions pour MySQL, PostgreSQL, SQLite ou SQL standard Il lit les clés d'objet sous forme de colonnes, déduit chaque type de colonne des données, échappe aux chaînes, transforme les clés manquantes et les valeurs nullesNULL(en anglais), et stocke les objets imbriqués en tant que JSON Tout s'exécute dans votre navigateur, donc une réponse API avec des données réelles ne quitte jamais votre machine Pour l'inverse ou pour les sources tabulaires, voir CSV à SQL et JSON vers CSV.
Que fait un convertisseur JSON vers SQL ?
JSON et SQL modélisent les données de manière fondamentalement différente JSON est un arbre d'objets imbriqués et de tableaux avec des types dynamiques par valeur Une table relationnelle est une grille plate de colonnes fixes et typées La conversion de l'une à l'autre est une série de petites décisions, et la valeur de l'outil est de prendre ces décisions de manière cohérente.
Il lit les clés de vos objets comme le jeu de colonnes, traite chaque objet comme une ligne, choisit un type SQL pour chaque colonne, puis écrit les instructions La sortie comporte deux parties : une facultative CREATE TABLE cela déclare les colonnes avec leurs types déduits, et le INSERT les instructions qui portent les valeurs Vous pouvez coller le résultat dans un client de base de données, l'enregistrer dans le cadre d'une migration ou le canaliser mysql, psql, ou sqlite3 de la ligne de commande.
L'entrée est normalement un tableau d'objets, comme [{ "id": 1, "name": "Ada" }, { "id": 2, "name": "Grace" }]. Un seul objet fonctionne aussi et devient une rangée Ce qu'il n'acceptera pas est un tableau de valeurs nues telles que [1, 2, 3](traduction), parce qu'il n'y a pas de clés à transformer en colonnes, et cela vous le dit plutôt que de deviner.
Comment les types de colonnes sont-ils déduits ?
C'est la partie qui sépare un convertisseur utile de celui qui déverse tout dans des colonnes de texte Pour chaque colonne, l'outil scanne la valeur dans chaque ligne et sélectionne le type le plus étroit qui correspond à toutes.
Si chaque valeur présente dans une colonne est un nombre entier, la colonne devient un type entier Si les valeurs sont des nombres mais que certaines ont des décimales, elle devient un type à virgule flottante Si chaque valeur est true ou false[TRADUCTION], cela devient un booléen Si chaque valeur est un objet ou un tableau imbriqué, cela devient un type JSON Tout le reste, y compris une colonne où les valeurs ne sont pas d'accord, revient au texte donc le INSERT ne peut pas échouer sur une inadéquation de type.
null et les clés manquantes sont sautées lors de la décision du type ; elles ne rendent la colonne nullable qu'en pratique Cela signifie une colonne qui contient des nombres dans la plupart des lignes et null dans quelques-uns est encore tapé comme un nombre, ce que vous voulez.
Le nom du type concret dépend du dialecte Voici comment les types neutres mappent :
| Type déduit | mysql | PostgreSQL | SQLite | SQL standard |
|---|---|---|---|---|
| Entier | INT |
INTEGER |
INTEGER |
INTEGER |
| décimal | DOUBLE |
DOUBLE PRECISION |
REAL |
REAL |
| Booléen | TINYINT(1) |
BOOLEAN |
INTEGER |
BOOLEAN |
| JSON imbriqué | JSON |
JSONB |
TEXT |
TEXT |
| Texte | VARCHAR(255) |
TEXT |
TEXT |
TEXT |
Vous pouvez désactiver entièrement l'inférence de type, auquel cas chaque colonne devient du texte C'est parfois ce que vous souhaitez lorsque vous chargez des données dans une table de transit et prévoyez de les diffuser plus tard.
Comment gère-t-il les parties gênantes des données réelles ?
Le vrai JSON est rarement uniforme, et la conversion doit faire face L'outil gère trois cas qui déclenchent des convertisseurs naïfs.
Premièrement, les objets avec des clés différentes Si un objet a un email champ et un autre non, l'ensemble de colonnes est l'union de chaque clé qui apparaît, conservée dans l'ordre vu en premier, et tout objet manquant de clé obtient NULL dans cette colonne. L'outil vous avertit lorsque les objets ne sont pas uniformes afin que vous ne soyez pas surpris.
Deuxièmement, les objets et les tableaux imbriqués Les colonnes SQL sont plates, donc une valeur comme { "street": "1 Main St", "city": "London" } ne peut pas devenir plusieurs colonnes automatiquement sans que vous décidiez la forme Au lieu de cela le convertisseur sérialise la valeur imbriquée de nouveau en texte JSON et le stocke dans une colonne JSON sur MySQL, une colonne JSONB sur PostgreSQL, ou une colonne de texte ailleurs La structure reste intacte et vous pouvez l'interroger plus tard avec vos fonctions JSON de base de données' ; s.
Troisièmement, les types mixtes dans une colonne Si un champ est un nombre dans un enregistrement et une chaîne dans un autre, forcer un type numérique ferait échouer la moitié des inserts L'outil détecte le désaccord et tape la colonne comme texte, puis cite chaque valeur comme une chaîne littérale pour que le lot s'exécute proprement.
Comment les valeurs sont-elles échappées ?
L'échappement correct est la différence entre un script qui s'exécute et un script qui lance une erreur de syntaxe sur la ligne 47. les règles appliquées par le convertisseur sont celles SQL standard.
Les valeurs du texte sont enveloppées dans des guillemets simples, et toute citation unique à l'intérieur d'une valeur est doublée, donc O'Brien se transforme 'O''Brien'. Ceci est la chaîne ANSI SQL s'échappant et cela fonctionne sur les quatre dialectes Les nombres et les booléens sont écrits sans guillemets, car un nombre cité est une chaîne dans la plupart des moteurs Les booléens rendent comme TRUE et FALSE sur PostgreSQL et SQL standard, et comme 1 et 0 sur MySQL et SQLite, correspondant à la façon dont chaque moteur les stocke. null et les clés manquantes deviennent le mot-clé non cité NULL.
Les identifiants, c'est-à-dire les noms de tableaux et de colonnes, sont également cités, avec des backticks sur MySQL et des guillemets doubles partout ailleurs. Cela garde une colonne nommée order ou select d'entrer en collision avec un mot réservé.
Comment utiliser le convertisseur JSON vers SQL
Étape 1 : Collez votre JSON
Gouttez un tableau d'objets, ou appuyez sur Charger l'échantillon pour voir la forme attendue Chaque objet devient une rangée.
Étape 2 : Nommez le tableau et choisissez un dialecte
Tapez le nom de la table cible et choisissez MySQL, PostgreSQL, SQLite ou SQL standard. Le dialecte contrôle le style de citation, les noms de types et la manière dont les booléens et les JSON imbriqués sont écrits.
Étape 3 : Définissez les options de sortie
Décider s'il faut inclure le CREATE TABLE: s'il faut déduire des types de colonnes et s'il faut émettre une ligne multi INSERT ou une instruction par ligne Un seul insert multi-rangées se charge plus rapidement ; une instruction par ligne produit un fichier adapté aux différences et vous permet d'exécuter des lignes individuellement.
Étape 4 : Copiez le SQL
Lisez les instructions générées et copiez-les Collez le script dans votre client de base de données ou exécutez-le depuis la ligne de commande pour créer et charger la table.
Cas d'utilisation courants
Ensemencement d'une base de données à partir d'une réponse API
Vous construisez une fonctionnalité et avez besoin de lignes réalistes pour travailler contre. Retirez une réponse JSON de l'API amont, collez-la et vous en avez un CREATE TABLE et insère prêt à semer votre base de données locale Pas de typage manuel, pas de devis manqués.
Transformation d'une configuration ou d'une exportation dans une table
Un service exporte ses données sous forme de tableau JSON Vous souhaitez exécuter des requêtes SQL ad hoc contre lui plutôt que d'écrire JavaScript pour filtrer le tableau Convertissez-le en SQL, chargez-le en SQLite et interrogez-le avec le langage construit exactement pour cela.
Construire une graine de migration
Les migrations de frameworks nécessitent souvent une étape de seed qui insère des données de référence Générer le INSERT les instructions d'un luminaire JSON connu vous donnent un bloc stable et révisable à coller dans la migration, plutôt que de traduire les données à la main.
Reproduire un bug de production localement
Un bug n'apparaît que pour un ensemble spécifique d'enregistrements Prenez le JSON pour ces enregistrements, convertissez-le en inserts, chargez-les dans votre base de données locale et reproduisez le problème sans copier une base de données de production.
Insert multi-rangées vs par rangée : lequel choisir ?
Un insert multi-rangées regroupe chaque ligne en une seule instruction avec plusieurs VALUES tuples. Il est compact et se charge le plus rapidement, car la base de données analyse et planifie une instruction au lieu de centaines Choisissez-la pour le chargement en vrac.
Une instruction par ligne est plus verbeuse mais présente deux avantages Elle produit un fichier où chaque ligne est sa propre ligne, qui se lit proprement dans une revue de code et se distingue bien dans le contrôle de version Et si une ligne viole une contrainte, les autres réussissent toujours, ce qui est pratique lorsque vous chargez des données désordonnées et que vous voulez voir quelles lignes échouent plutôt que de perdre le lot entier Choisissez-le pour les graines que vous allez valider ou pour les données auxquelles vous n'avez pas encore entièrement confiance.
Exécution du SQL généré à partir de la ligne de commande
Une fois que vous avez le script, le chargement est un one-liner dans chaque moteur Pour SQLite, enregistrez la sortie dans un fichier et pipez-le dans : sqlite3 mydata.db < insert.sql crée la table et charge les lignes dans un nouveau fichier de base de données Pour PostgreSQL, psql -d mydb -f insert.sql exécute l'intégralité du script par rapport à la base de données nommée Pour MySQL, X, X, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y, Y mysql -u user -p mydb < insert.sql fait de même Parce que le générateur cite des identifiants et échappe aux valeurs du dialecte que vous avez choisi, le script s'exécute sans les correctifs manuels dont SQL écrit à la main a habituellement besoin.
Si vous avez généré une instruction par ligne plutôt qu'un seul insert multi-rangées, envelopper la charge dans une transaction vaut la peine d'être ajouté BEGIN; en haut et COMMIT; en bas tourne des centaines d'inserts individuels en une seule opération atomique, qui est à la fois plus rapide et plus sûre : si une rangée ultérieure échoue à une contrainte, toute la charge recule au lieu de laisser la table à moitié peuplée Pour un insert multi-rangées c'est déjà effectivement atomique, puisqu'il s'agit d'une seule instruction.
Performances et limites avec de grands tableaux
La conversion elle-même est linéaire dans la taille de l'entrée et s'exécute entièrement dans votre navigateur, donc quelques milliers de lignes convertissent instantanément Les limites pratiques ne sont pas dans l'outil mais dans ce que vous faites avec la sortie Une seule multi-rangée INSERT avec des dizaines de milliers de tuples, vous pouvez dépasser une base de données & #39 ; la taille maximale de l'instruction ou la limite de paquets, MySQL' ;s max_allowed_packet étant celui que les gens frappent en premier Si vous chargez un très grand tableau, soit passez à une instruction par ligne donc chacune est petite, soit divisez l'entrée en lots de quelques centaines de lignes et convertissez-les séparément.
Il y a aussi une mise en garde de précision qui mérite d'être connue Les nombres JSON sont analysés par le navigateur' ; le moteur JSON est transformé en flotteurs standard à double précision, donc un entier supérieur à environ neuf quadrillions, au-delà de JavaScript' ; sa plage entière sûre, peut perdre en précision avant que l'outil ne le voie. C'est une propriété de JSON qui analyse dans chaque environnement, pas du convertisseur, mais cela signifie qu'un identifiant numérique géant est plus sûr représenté comme une chaîne dans le JSON source, que l'outil stockera ensuite sous forme de texte et préservera exactement.
Où cela s'adapte à d'autres outils
JSON vers SQL est une direction d'une petite famille Lorsque votre source est une feuille de calcul ou une exportation CSV plutôt que JSON, CSV à SQL fait le même travail à partir d'une entrée tabulaire avec le même type d'inférence et d'échappement Lorsque vous avez besoin des données comme un fichier plat au lieu d'une base de données, JSON vers CSV aplatit le tableau en rangées, et CSV à JSON remonte dans l'autre sens Avant de convertir quoi que ce soit, Formateur JSON va joli-imprimer et valider le JSON pour que vous attrapez une virgule parasite avant qu'elle ne devienne une erreur d'analyse Et une fois que vous avez le SQL, Formateur SQL indentera et alignera les instructions d'un fichier de migration que vous êtes fier de commettre.
Pour le raisonnement derrière tout cela dans le navigateur plutôt que de télécharger des données vers un service de conversion, le Confidentialité des données dans les outils en ligne le guide présente le modèle côté client et le Boîte à outils pour les développeurs Web collecte les utilitaires qui se couplent bien avec le travail de conversion de données.
FAQ
Comment convertir-je JSON en SQL ?
Collez un tableau JSON d'objets, définissez le nom de la table et choisissez votre dialecte SQL. L'outil lit les clés d'objet sous forme de noms de colonnes, infère chaque type de colonne et génère une TABLE DE CRÉATION plus INSERT instructions que vous pouvez copier et exécuter dans votre base de données.
Quelle forme JSON accepte-t-il ?
Un tableau d'objets est l'entrée normale, où chaque objet est une ligne Un seul objet fonctionne et produit également une ligne Les tableaux de primitives ou de formes profondément incompatibles sont rejetés avec une erreur expliquant ce qui est attendu.
Quelles bases de données SQL sont prises en charge ?
Le convertisseur génère des instructions pour MySQL, PostgreSQL, SQLite et SQL standard. Le dialecte que vous choisissez contrôle le devis d'identifiant, le type et la syntaxe booléenne, ainsi que le type JSON natif, de sorte que le script s'exécute dans cette base de données sans modifications.
Comment les types de colonnes sont-ils décidés ?
Chaque colonne est cochée par rapport à chaque objet Si toutes les valeurs présentes sont des nombres entiers elle devient un type entier, tous les nombres deviennent un type décimal, toutes les valeurs vraies ou fausses deviennent un type booléen, tous les objets ou tableaux deviennent un type JSON, et tout ce qui est mélangé devient du texte.
Qu'arrive-t-il aux objets et tableaux imbriqués ?
Ils sont sérialisés en retour au texte JSON et stockés dans une colonne JSON sur MySQL, une colonne JSONB sur PostgreSQL, ou une colonne TEXT sur SQLite et SQL standard Cela garde la structure intacte afin que vous puissiez l'interroger avec vos fonctions JSON de base de données plus tard.
Et si mes objets ont des clés différentes ?
C'est bien Les colonnes sont l'union de chaque clé qui apparaît, gardée dans l'ordre vu en premier Tout objet manquant d'une de ces clés obtient NULL dans cette colonne, et l'outil vous avertit lorsque les objets ne sont pas uniformes.
Comment les chaînes et les citations sont-elles échappées ?
Les valeurs du texte sont enveloppées dans des guillemets simples et toute citation unique à l'intérieur d'une valeur est doublée, ce qui est l'échappement SQL standard Les nombres et les booléens ne sont pas cités, nul devient NULL et les identifiants sont cités avec des backticks pour MySQL ou des guillemets doubles pour les autres dialectes.
Mon JSON est-il téléchargé quelque part ?
No. Parsing et la génération SQL s'exécutent en JavaScript dans votre navigateur Rien n'est transmis, enregistré ou stocké, et l'outil continue de fonctionner hors ligne une fois chargé, ce que vous pouvez confirmer en regardant l'onglet réseau pendant que vous convertissez.
