Discussion :

[Michel.Priori]

Bonjour à tous,

L'inclusion des données semies structurées, comme le Json, dans le SQL me pose des problèmes.

Le point le plus évident est que cela contrevient largement au concept d'information non décomposable.
Mais, il est notoire que tout le monde accepte la redondance de donnée que représente les index parce que ... tout un tas de raisons qui font que ce n'est pas/plus un problème.

Si on garde le parallèle avec les index, on sait que le bilan est positif, mais à condition de respecter tout un tas de trucs.
On a une belle littérature qui disserte de la chose.

Je voudrais simplement savoir comment continuer à appliquer les formes normales en intégrant du Json.
Existe t'il des "cas d'usage" où la normalisation traditionnelle n'est structurellement pas la meilleure option ?

[Sve@r]

Bonjour

Mais, il est notoire que tout le monde accepte la redondance de donnée que représente les index parce que ... tout un tas de raisons qui font que ce n'est pas/plus un problème.

Le fait que X ait été accepté n'est pas une raison pour justifier de l'acceptation de Y. Les index ont une utilité en termes de performances dans la recherche et c'est en raison de cette utilité qu'on accepte de prendre en charge les contraintes qui vont avec. Accepter les index a nécessité des études et des réflexions et il sera nécessaire de refaire d'autres études et d'autres réflexions si on veut intégrer un autre concept.

Je voudrais simplement savoir comment continuer à appliquer les formes normales en intégrant du Json.

Désolé tu ne peux pas. Les formes normales ont été établies dans le but de créer des bdd relationnelles "optimales". Tu ne peux pas appliquer à Pierre une technologie dédiée à Paul. C'est comme si tu voulais appliquer à un hélicoptère le système de transmission par chaine des motos.

Existe t'il des "cas d'usage" où la normalisation traditionnelle n'est structurellement pas la meilleure option ?

La bdd relationnelle normalisée a l'avantage de supprimer les redondances en les remplaçant par des associations. Avantages en terme d'occupation et de mises à jour mais inconvénients en terme de coût pour récupérer les données éparses lors de la requête. Le json (et autres structures "nosql") vient s'insérer lorsque la rapidité dans la recherche devient plus important que celui de l'occupation et la mise à jour. Google par exemple stocke ses infos dans une bdd "nosql".

[SQLpro]

Regardez le chapitre 2 du livre sur le SQL que je viens de publier...
https://sqlpro.developpez.com/livre/...aleurs-et-null

Notamment le §
II-1-5. Les types « larges » (LOB)
JSon comme XML font partie de la norme
Les principes de manipulation de es données ont été publiées par la norme SQL depuis bien longtemps.

Le problème est juste de savoir si ce que vous y stockez est un objet unique ou une collations d'objet... Dans ce dernier cas vous violez la 1FN...

A +

[SQLpro]

Un exemple simple de cas d'usage est celui des données informatives n'ayant que très peu ou pas de recherches et très peu de mise à jour, et qui dans beaucoup de cas serait NULL...

C'est celui de l'adresse.

Si l'on suit les formes normales et la décomposition de l'adresse suivant la norme de l'adresse, le bon modèle est celui que j'ai donné ici :
https://blog.developpez.com/exercice..._d_une_adresse

Le problème est que cela ne suffit pas pour un livreur qui a besoin d'informations complémentaires si elles existent...

• digicode,
• bâtiment,
• escalier,
• interphone,
• étage,
• porte,
• ...

Une structure XML du genre :

Code :

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

1
2
3
4
<complementAdresse>
   <etage>7</etage>
   <porte>face</porte>
</complementAdresse>

Sera très utile...

Sans compter les nombreux flux XML ou JSON que l'on reçoit et qu'il est important de conserver au moins un certains temps pour d'ultérieures vérifications....

Et la norme SQL a elle même ajouter les type ARRAY, ROW, RECORD et REF, dont je suis peu fervent !

A +



...

[Michel.Priori]

[...] cas d'usage est celui des données informatives n'ayant que très peu ou pas de recherches et très peu de mise à jour, et qui dans beaucoup de cas serait NULL [...]

J'en arrive aussi à ce genre de considérations, mais ça reste flou, et donc dangereux.
Du coup pour "auditer" l'existant ça reste très compliqué : arguments d'autorité, condition d'exploitation à monitorer et résultat à mettre en perspective du délais de mise à jour de la structure, ...

Pour ma part je considère que ce type de données est approprié dans le cas de données "polymorphes", comme l'est le contenu d'un dossier médical ;
Pour bien faire faudrait créer une table par type de d'analyse (de sang, d'urine, radiologique) et de maintenir les colonnes présentes.
Et au final on obtient une requête farcie de outer join, car tous les dossiers n'ont pas obligatoirement au moins une analyse de chaque.
Sauf à considérer le temps de traitement pour de la recherche médicale (analyses sur le contenu des documents) est l'axe majeur d'interrogation et l'objet du traitement des données en base.

Le truc qui me déplait c'est que c'est la porte ouverte à tous les arguments de dénormalisation (surtout de ceux qui n'ont pas fait l'effort d'avoir un référentiel "normalisé")

[SQLpro]

Deux autres exemples assez similaires dans leur usage l'un dans le médical... et l'autre plus généraliste

L'histoire de la maladie.... Dans tous les hôpitaux pour les longues maladie on créé un document dans lequel chaque médecin enregistre au fil du temps ses constatation et un résumé du traitement, des soin et médicaments.... Là je créée du XML avec une entrée relativement libre, mais j'y ajoute automatiquement les noms, prénom et qualité du rédacteur ainsi que la date de saisie des informations.

Chaque fois que l'on me demande de rajouter une colonne "note" ou "observation" dans une table, je la fait en XML en rajoutant aussi les noms et prénom du rédacteur ainsi que la date de saisie des informations. Et je présente cela dans l'ordre chronologique inverse.... Cela responsabilise les gens qui écrivent afin qu'ils ne mettent pas n'importe quoi...

A +