Discussion :

[Neckara]

Bonjour,

Imaginons des données XML :

Code :

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

1
2
3
4
5
6
7
8
9
<root>
    <book/>
    <book name="H2O2" />
    <book>
           <page>
                 <font id='43' />
           </page>
    </book>
</root>

On peut fournir une interface très simple à l'utilisateur :

Code :

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

book[2].page.font['id'] = '42';

Mais, un fichier XML n'est pas un SGBD et ne fournit pas directement certaines fonctionnalités ainsi que les optimisations liées :

• les index ;
• les vues ;
• les clauses WHERE/HAVE/GROUP BY
• etc.

Je pensais alors qu'il serait intéressant de stocker ces données dans une BDD SQLite pour bénéficier des avantages des SGBD tout en conservant au maximum ceux des XML.
Le but serait donc de pouvoir proposer un système de requêtes "intuitives" du type :

Code :

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

1
2
3
4
SET book[2].page.font['id'] = '42'
INS page INTO rootbook[2] // ajoute une page à book[2]
GET book.page.font['id'] WHERE ISSET(book.page.font['id'])
DEL book.page.font['id'] WHERE ISSET(book.page.font['id'])

Puis de "traduire" ces requêtes intuitives en requêtes SQL.
La traduction ne devrait pas être très compliquée c'est surtout la structure de la BDD qui me pose problème :

• soit je fais une table book, une table page, une table font, etc. mais j'ai peur que les jonctions entre les tables ne coûte très cher au fur et à mesure qu'on aura de "générations", et donc se révèle moins intéressant qu'un bête fichier XML
• soit je fais des tables à deux colonnes : clé-valeur : ("book[2].page.font['id']", "42"), ("book[2].page", ""), etc. mais je ne sais pas si cela serait vraiment intéressant.

J'ai aussi entendu parler du NoSQL ce qui correspondrait à des couples "clé-valeur", mais je ne comprend pas comment il fonctionne en interne ni même s'il serait vraiment intéressant dans mon cas. Ni même s'il existe des SGBD NoSQL qui, comme SQLite, ne nécessite pas un service tournant en tâche de fond.

Est-ce que vous auriez des idées ou des suggestions ?

EDIT : JSONB de postgresql se rapproche de ce que je voudrais faire.

[Neckara]

Je pense à une structure comme celle-ci :

Id	Nom Hash (Index)	Hash Parent	Nom	Identifiant	Fils Positions (Index)
1 2 3 4	Hash("Book") Hash("Book/Page") Hash("Book") Hash("Book/Couverture/Page")	Hash(0) Hash(Book) Hash(0) Hash(Book/Couverture)	Book Book/Page Book Book/Couverture/Page	0 1 2 1	1 11 2 311

=> permet de trouver très rapidement un élément

Code :

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

book[*].page[0] : => SELECT * FROM T1 WHERE NomHash=hash(book.page) AND FilsPosition LIKES '%1'

=> permet de trouver très rapidement les fils/parents d'un élément.

Pour les attributs :

Identifiant (Index)	Nom Attribut	Valeur
2 3	id name	'42' 'H2O2'

=> permet de trouver très facilement un attribut d'un élément

=> pour récupérer un attribut :

Code :

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

SELECT t1.Valeur, t2.valeur FROM Table as t1, Table as t2 WHERE t1.NomAttribut = 'id' AND t2.NomAttribut = 'name' AND t1.Indentifiant = t2.Identifiant

Rq : INNER JOIN ?

Il ne manque plus que la "sélection des entrée" = clause WHERE.

[StringBuilder]

Sinon, pour information, il y a un type "XML" dans SQL Server.
Il permet de faire cohabiter SQL et XML Path dans la même requête.
Il s'avère aussi que ce type est, contre toute attente, très performant (bien plus que des méta-modèles trop élaborés).

[Neckara]

Là, comme je n'ai pas une quantité de données pharamineuse, je vais me contenter d'une structure simple :

Book

Id	Attribut A	Attribut B
1 2	58	foo

Book.Page

Id	Parent ID	Attribut A
1	2	42

Ce ne sera peut-être pas super optimisé, mais cela aura le mérite de faire des requêtes simples.

[SQLpro]

Sinon, pour information, il y a un type "XML" dans SQL Server.
Il permet de faire cohabiter SQL et XML Path dans la même requête.
Il s'avère aussi que ce type est, contre toute attente, très performant (bien plus que des méta-modèles trop élaborés).

Et rajoutons : indexable (pour les performances), typable via XML Schema et "mise-à-jourable" (on peut modifier le XML par ajout, modification ou suppressions de nœuds, éléments)...

Je viens de m'amuser avec cela pour la DDTM du Gard ou ou avons fait un méta modèle générique pour piloter les outils de communication pour l'interrogation des capteurs de surveillance des cours d'eau !

A +