Discussion :

[ludovic tambour]

Hello tout le monde

J'ai une application contenant une structure fortement arborscente d'objets. Cette structure est dynamique (eg. en cours d'exécution de nouveaux noeuds peuvent apparaitre, d'autres disparaitres).

A un moment donné, je souhaite sauvegarder physiquement la structure ainsi que les données présentes dans les noeuds. Plus tard, je souhaite restaurer la structure et données

Comme moyen de sauvegarde, j'ai le choix entre fichier XML et base de données.

Que me conseillez vous stp en terme de :
- rapidité à l'exécution
- facilité à programmer
- flexibilité au changement de spec

Merci d avance pour les reponses

Bon we

Ludo

[bruno_pages]

Hello,

Que me conseillez vous stp en terme de :
- rapidité à l'exécution
- facilité à programmer
- flexibilité au changement de spec

certainement pas XML !

XML est un moyen d'échange (très coûteux) entre parties ne se connaissant pas : ne pas utiliser pour échanger des données entre des softs d'on on a la maîtrise.

XML n'est certainement pas un moyen de sauvegarde. XML est très lent à lire, et totalement incompatible avec des modifications de spec.

Donc surtout ne pas faire comme plusieurs soft utilisant XML (ou XMI ) pour leur sauvegarde, ils ont commit cette erreur, c'est tant pis pour eux

[millie]

J'ai bossé récécemment sur quelque chose du genre (sauf que la bonne blague étant que l'arbre n'était pas vraiment un arbre (ce qui avait été écrit dans le cahier des charges), mais pouvait finalement être un graphe).

La méthode était (grosso modo) de stocker les arêtes du graphe dans une base de donnée, par exemple :

Code :

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

1
2
3
4
5
 
ORIGINE     DESTINATION
A              B
B              C
C              A

En terme de rapidité, si le SGBD est loin, la reconstruction de l'arbre peut être assez lente (il est nécessaire de faire au minimum n requêtes si l'arbre contient n sommets). 0.1 seconde par requête avec 1000 sommets = 100 secondes d'attente pour la construction (j'utilisais personnelement une base DB2 qui se trouvait pas tout prêt et c'était dans cette ordre d'idée)

La construction n'est pas trivial (quoique, si tu es sûr que les données sont sous forme d'un vrai arbre, c'est plus simple).

Si l'arbre peut être très profond, celà peut poser des problèmes pour la construction (j'avais une profondeur maximum de 20, je pouvais me permettre de faire des appels récursifs sans me soucier d'un dépassement de pile).

Et niveau, spec, bah, tant que ça reste un arbre/graphe, il est toujours possible d'ajouter des éléments (un label sur l'arc), ou sur les sommets (nécessite la création d'un autre table).

[Hephaistos007]

XML n'est certainement pas un moyen de sauvegarde. XML est très lent à lire, et totalement incompatible avec des modifications de spec.

Ca va pas faire plaisir aux sociétés qui développent des BDD en XML natif ca !

Quant aux modification de specs, je ne sais pas ce que ca veut dire, mais si vous parlez de modifier un schema XML, par définition c'est tout aussi difficile que de modifier un schéma de BDD.

[mandale]

je pense que le format xml est utile pour stocker un objet contenant des collections , etc....bref ayant une "profondeur".
Cela peut etre un bon moyen de sérialiser l'état d'un objet autre que dans un format binaire comme le propose certains serveur d'applications


de plus la recupération xml permet un parsing efficace pour un affichage web
directe...
C'est sympa pour la creation d'un report et la transformation en fichier...

une base sql n'est pas adaptée au model objet quoi qu'on en dise
je vous passe les jointure en cascade et la pose d'index et nanana ....


d'ailleur quand j'ai un objet je dois passer par un mapping objet / relationnel
pour le sauver
belle connerie de middleware....



bref le xml comme le sql , c'est bien mais pas top

[millie]

une base sql n'est pas adaptée au model objet quoi qu'on en dise
je vous passe les jointure en cascade et la pose d'index et nanana ....

Dans son problème, il n'est pas utile d'écrire une seule requête avec une jointure (mais je sais pas si tu parlais en général ou de son problème).

d'ailleur quand j'ai un objet je dois passer par un mapping objet / relationnel
pour le sauver
belle connerie de middleware....

Dès que les requêtes sont délicates (où peuvent dépendre de plusieurs tables), il vaut mieux passer par d'autre framework (genre JDBC).

Mais attention, on est pas obligé d'avoir des objets persistants avec un mapping objet/relationnel.

[Nip]

une base sql n'est pas adaptée au model objet quoi qu'on en dise

Bien sur, de la meme maniere que les langages objets qu'on a a dispo actuellement ne sont pas pleinement objet et ne permettent pas d'implementer tous les precepts objets... mais en attendant d'avoir plus performant les SGBDR sont ce qu'il y a de mieux, de plus rapide et de plus accessible passe une certaine taille de donnees. Sinon t'as toujours la possibilite de te tourner vers une base objet comme db4o qui marque un peu le debut des bases objets.

bref le xml comme le sql , c'est bien mais pas top

Je suis bien d'accord mais en attendant on fait avec

[Erwy]

XML est un moyen d'échange (très coûteux) entre parties ne se connaissant pas : ne pas utiliser pour échanger des données entre des softs d'on on a la maîtrise.

C'est un moyen d'échange tout court qui offre en plus l'avantage non négligeable d'être facilement lisible par un être humain, ce qui n'est ps le cas de tous les autres formats

XML n'est certainement pas un moyen de sauvegarde. XML est très lent à lire, et totalement incompatible avec des modifications de spec.

Faux surtout la partie très lente, du moins pour des volumes moyens ou petit < 10 mega et sin on choisit bien les methodes d'acces/rendu
Si on fait du transactionnel la différence d'accès sur un sgbdr et un fichier XML "moyen" en asp (pas le .net, le vieux clous) la différence d'accès est invisible pour l'utilisateur.
De même d'ailleurs que pour certaines requêtes on preferait , pour un pb de temps de réponses, extraire des fichiers à plats et les parser, on peut faire de même avec des fichiers XML (notamment multiples jointures externes)

Donc surtout ne pas faire comme plusieurs soft utilisant XML (ou XMI ) pour leur sauvegarde, ils ont commit cette erreur, c'est tant pis pour eux

C'est plus que la tendance actuelle pourtant , et ce n'est pas une mode

Comme pour un SGBDR tout ce pose au niveau de la pertinence de la structure choisie, des outils d'extraction/rendu choisis et de leur corespondance avec le but recherché

[ludovic tambour]

Merci pour vos réponses. Je ne pensais pas que cette question allait succité un bon débat.

Si j'ai le temps, je vais essayer les deux. J'avais une préférence pour le XML car la structure hiérachique d'un fichier XML est proche de celle de ma structure arborescence. Donc, la sauvegarde et la restauration est facilité. Je vais quant meme essayer la solution base de données et comparer. Je vais essayer la solution proposée par le chapitre 4 de http://xml-persistence.prefetch.com/...ersistence.pdf

Encore merci

Ludo

[Erwy]

Pour les données de type documentaires, article, contrat etc...
il existent 2 variantes incluant XML (qui code tres bien ce type de format)
- stockage de XML dans une base de donnée relationnelle , sachant que les leaders du marché donnent des outils de recherche comme XQuery ou via le SQL(oracle me semble fournir les deux,ms sql et db2 ont au moins xquery je crois)
-stockage dans des base de donnée xml native, elles sont de plus en plus utilisé pour l'archivage de documentation

[Hephaistos007]

Pour les données de type documentaires, article, contrat etc...
il existent 2 variantes incluant XML (qui code tres bien ce type de format)
- stockage de XML dans une base de donnée relationnelle , sachant que les leaders du marché donnent des outils de recherche comme XQuery ou via le SQL(oracle me semble fournir les deux,ms sql et db2 ont au moins xquery je crois)
-stockage dans des base de donnée xml native, elles sont de plus en plus utilisé pour l'archivage de documentation

Pour compléter la réponse d'erwy, je renvoi ceux que ca intéresse à un de mes anciens post sur le sujet : http://www.developpez.net/forums/sho...1&postcount=10