Discussion :

[medchok]

Bonjour,

Je cherche à faire passer des données récupérées au format json dans une base de données (un table, pour faire simple).
Le premier grand problème est que je n'ai aucune indication, préalable à l'exécution de mon programme (une fois fonctionnel), sur la structure des données json récupérées.

Ce serait bien gentil de bien vouloir m'indiquer un moyen me permettant d'identifier la structure de mes données afin de pouvoir créer la table (BD) avec la même structure (encore pour faire simple en supposant qu'il n'y a pas d'imbrications).

Vous remerciant d'avance pour vôtre intérêt

[wiztricks]

Ce serait bien gentil de bien vouloir m'indiquer un moyen me permettant d'identifier la structure de mes données afin de pouvoir créer la table (BD) avec la même structure (encore pour faire simple en supposant qu'il n'y a pas d'imbrications).

Ce genre de chose n'existe pas (en dehors de cas triviaux).

- W

[Sve@r]

Bonjour

Le premier grand problème est que je n'ai aucune indication, préalable à l'exécution de mon programme (une fois fonctionnel), sur la structure des données json récupérées.

Sans même parler de l'incongruité de cet état de fait (généralement un donneur d'ordre sait ce qui passe dans ses tuyaux, ou au pire sait ce qu'il voudrait qu'il passe), ce problème reste incontournable.

[medchok]

Merci pour vôtre intérêt et vos interventions et réflexions.

Je dois juste vous dire que c'est bel et bien une situation réelle où le programme en question devra recevoir des données multi-sources et multi-structures (non toujours définies, même par source) et les basculer vers une BD où il ajoutera, si besoin est, un certain nombre de champs.

Merci encore pour vos réponses

[Sve@r]

Si vraiment tu n'as aucun support commun permettant d'unifier le tout, comme par exemple "toutes les datas auront un nom et un prénom", alors dans ce cas là, la seule solution est de stocker en bdd la data reçue "telle quelle".
Une table par exemple "reception" contenant la date de réception, éventuellement l'émetteur, plus d'autres champs d'identifications de ton cru, plus le flux reçu sans tenter de le "rétro-ingeniérer" car cela n'est pas possible.

[Arioch]

Merci pour vôtre intérêt et vos interventions et réflexions.

Je dois juste vous dire que c'est bel et bien une situation réelle où le programme en question devra recevoir des données multi-sources et multi-structures (non toujours définies, même par source) et les basculer vers une BD où il ajoutera, si besoin est, un certain nombre de champs.

Merci encore pour vos réponses

A mon travail, nous sommes confrontés à ce cas de figure : beaucoup de sources différentes récupérées en JSON et on doit travailler ces données.

Nous avons choisi d'utiliser une base de données par source afin de limiter les champs inutiles d'une source à l'autre. Et nous conservons dans chaque base le JSON reçu.

Peut être qu'une base de données par source est too much pour votre besoin (pas le nôtre en tous cas), mais vous devriez peut être revoir votre manière de stocker vos données.

Ca nous est déjà arrivé de "tailler" dans un champ, revoir sa longueur max à la volée si c'était nécessaire en recevant de nouvelles données. Mais créer des nouveaux champs...

Sinon, au cas où vous auriez besoin de traiter beaucoup de champs dans vos JSON et que vous voudriez rapidement connaître le type de champs à créer dans votre future base de données, il y a un site internet permettant d'identifier les champs d'un contenu de fichier JSON et surtout, le typage de chacun d'eux.

Ce site est utilisé pour générer automatiquement des classes s'appuyant sur pydantic mais ça peut aussi vous permettre de préparer votre modèle de future table. Ca vaut ce que ça vaut.

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
{
    "titre_album":"Abacab",
    "groupe":"Genesis",
    "annee":1981,
    "genre":"Rock"
}

Génèrera automatiquement la classe suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
from __future__ import annotations
 
from pydantic import BaseModel
 
 
class Model(BaseModel):
    titre_album: str
    groupe: str
    annee: int
    genre: str

Si vous devez reprendre les noms de champs tels quels pour la table, vous les avez, ainsi que leur typage.

JSON to Pydantic

[wiztricks]

Je dois juste vous dire que c'est bel et bien une situation réelle où le programme en question devra recevoir des données multi-sources et multi-structures (non toujours définies, même par source) et les basculer vers une BD où il ajoutera, si besoin est, un certain nombre de champs.

Une solution a éventuellement explorer est côté base de données non-relationnelles: on pousse les JSON dans un gros tas musclé en disques et en unités centrales pour faire des query.
Une autre solution est à chercher du côté des ETL qui permettent de réaliser un mapping facilement.

Dans tous le cas, vous n'en êtes pas à programmer quoi que ce soit avec Python (mais à définir les composants clefs d'une application en cours de conception).

- W

[papajoker]

bonjour

recevoir des données multi-sources et multi-structures (non toujours définies, même par source) et les basculer vers une BD où il ajoutera, si besoin est, un certain nombre de champs.

Pour moi, demande vraiment pas claire, si la source json n'est même pas assez, comment ton programme (et nous) peut deviner ? te reste à écrire l'algorithme "devin" ?
Ou, alors la demande est de simplement faire un programme interactif de conversion ?

Que peut-on faire des datas si on ne connait pas la stucture ? en fait rien à part de la sauvegarde (alors il faut le dire et la demande est 1000 fois plus simple), sinon puisque l'on ignore la stucture, il sera impossible de faire des requêtes sur ces tables

Certaines bases de données peuvent gérer le json en natif et même faire des requetes "json" (mais il faut quand même connaitre la structure json pour faire une requête, ce qui ne semble clairement pas être le cas avec cette demande...)

Existe de nombreux "outils" (un donné par Arioch) pour convertir un json en un fichier de type (par exemple, puisque Go est un langage typé, il est normal de déclarer la structure du json avant même compilation), il est bien sûr assez simple d'écrire un tel outil en python adapté à notre propre besoin

[Sve@r]

sinon puisque l'on ignore la stucture, il sera impossible de faire des requêtes sur ces tables

Surtout que dans les bdd, on crée d'abord les tables avec les colonnes attendues/prévues. Alors que dans ce cas présent, il faudra(it) créer les tables quand la data arrive. Et au final on aura(it) autant de tables que de json reçu mais des tables n'ayant aucune relation entre elles. Bref dans ce cas la bdd (rappel : on parle de bdd "relationnelle") devient inutile et on stocke simplement le json reçu dans un fichier.