Créer une base depuis XML ou JSON

Outils → Recréer la BD depuis XML / JSON prend un document XML ou JSON, déduit la structure relationnelle qu’il contient et construit une base à partir de celui-ci — tables, colonnes, types, relations et données.

C’est utile lorsqu’un système vous remet un gros export — un catalogue de produits, un jeu de données médical ou pharmaceutique, un dump d’API, le fichier de données d’un partenaire — et que vous le voulez sous forme de vraie base plutôt que de fichier.

Quatre formats sont acceptés : .xml, .json, et le JSON délimité par lignes en .jsonl ou .ndjson. Le format est déterminé par l’extension du fichier ; tout ce qui suit l’analyse initiale est commun, de sorte que l’aperçu, le DDL généré et le chargement se comportent de la même façon quel que soit le format de départ.

Les trois étapes

1. Configuration

• Fichier XML / JSON — choisissez le document.
• Connexion cible — où la base sera créée.
• Base de données cible — le nom de la base. Pour SQLite, il s’agit du fichier de base de la connexion.

2. Aperçu

NabuSQL analyse le document et affiche ce qu’il a trouvé : les tables qu’il va créer, leurs colonnes et les types déduits. Le DDL généré peut être examiné avant toute exécution.

Lisez attentivement cette étape. C’est là que vous découvrez qu’un champ que vous pensiez numérique a été déduit comme texte parce qu’un enregistrement sur cinquante mille contient un caractère parasite.

3. Exécution

L’import s’exécute avec une progression par table. À la fin, vous obtenez un résultat par table : lignes chargées et éventuelles erreurs.

Comment la structure est déduite

Depuis XML

Les éléments répétés deviennent des tables. Les attributs et le texte des éléments deviennent des colonnes. Un élément qui n’apparaît qu’une fois dans son parent est intégré à ce parent sous forme de colonnes préfixées — un bloc <meta><author>…</author></meta> devient une colonne meta_author plutôt qu’une table à une seule ligne.

Depuis JSON

Le même principe, exprimé dans le vocabulaire de JSON :

Dans le document	Dans la base
Clé contenant un scalaire	Colonne de la table de cet objet
Clé contenant un objet	Intégrée au parent sous forme de colonnes préfixées
Clé contenant un tableau	Table enfant avec une clé étrangère vers le parent
Scalaire seul dans un tableau	La colonne _text de la table

JSON exprime une chose plus clairement que XML : un tableau signifie « plusieurs » même lorsque ce fichier précis ne contient qu’un seul élément, il devient donc une table quelle que soit sa longueur. XML doit déduire la même chose de la répétition d’une balise, ce qui fait qu’un élément enfant unique ressemble exactement à une collection qui n’aurait qu’un seul membre.

Un tableau au niveau racine est traité comme une liste d’enregistrements racine. Un objet au niveau racine est un seul enregistrement racine. Avec .jsonl / .ndjson, chaque ligne est un enregistrement racine et les lignes vides sont ignorées.

Comme JSON n’a pas de balise racine pour nommer les choses, c’est le nom du fichier qui fournit le nom de la table racine — catalog.json produit une table catalog.

Fonctionnement

Trois aspects de l’implémentation comptent en pratique :

• Analyse en deux passes. La première passe détermine la structure, la seconde charge les données.
• Mémoire. Le XML et le JSON délimité par lignes sont lus en flux, la taille du fichier est donc limitée par le disque plutôt que par la RAM. Un fichier .json ordinaire est une seule valeur JSON et doit être analysé en entier, donc un très gros fichier est limité par la mémoire. Si vous maîtrisez l’export, demandez du .ndjson.
• Les clés étrangères sont appliquées après le chargement des données. Les enregistrements sont souvent ordonnés de sorte qu’un enfant arrive avant son parent ; créer les contraintes dès le départ rejetterait des lignes parfaitement valides. Les contraintes sont posées à la fin, une fois toutes les lignes en place.

Ensuite

• Vérifiez les types déduits dans Tables et colonnes et resserrez tout ce qui est sorti plus large que nécessaire.
• Ouvrez le diagramme ER pour voir la structure déduite.
• Ajoutez des index sur les colonnes que vous interrogerez réellement — l’import crée les clés et les contraintes, pas les index dont vos rapports ont besoin.

Si une table ne sort pas comme prévu

La structure suit le document. Lorsqu’un champ est incohérent d’un enregistrement à l’autre, l’analyse élargit le type pour accueillir toutes les valeurs rencontrées. Corriger cela après le chargement — un ALTER TABLE sur un jeu de données sain — est généralement plus rapide que de remanier le fichier source.

Les booléens sont une surprise fréquente : les true / false de JSON sont stockés en 1 / 0, la colonne sort donc en entier plutôt qu’en texte.