XML ou BDR ?

Bonjour à tous,

Certains disent que l'XML est employé pour les petits modèles de données et que dès lors où ces derniers deviennent trop gros il faut utiliser une base de données relationnelles. Ma question est donc ou se trouve la frontière de décision?
Y a t-il un taux définit? genre 5000 tuples... Jusqu'où est la limite d'XML?
Je conçois que beaucoup de paramètre entre en jeux tel que le nombre de connexion au site web etc... Mais si on fait abstraction de cela. A partir de quand mon traitement d'arbre devient-il vraiement une mauvaise solution?
Tout ca pour dire que cette question me turlupine et que je vous sollicite pour une reflexion de groupe et souhaite bénéficier de votre expérience.

Merci à tous.

Bonjour,

quand tu parles de XML, s'agit-il de XML dans un fichier ou dans une base de données XML ? Dans le premier cas, la moindre manipulation va nécessiter un parsing du fichier et au-delà d'un ordre de grandeur de la dizaine de Mo le temps de réponse risque d'être prohibitif pour une application Web. Dans le cas d'une base de données native XML, disposant d'une indexation et d'un langage de requête évolué (XQuery), la limite est beaucoup plus haute ; il existe sur le site de eXist des références à des bases de plus de 1 Go.

Bonjour GrandFather,

Effectivement je n'ai pas été très claire sur ce point et je m'en excuse.
En effet, je pensais surtout à ton premier cas à savoir l'utilisation d'XML dans un fichier.
Je n'arrive pas à me représenter ton ordre de grandeur de la dizaine de Mo dont tu parle. Imaginons que j'ai un arbre dont la profondeur max est de 4 par exemple. Cela revient à limiter cet arbre à combien de noeud fils, partant de ta racine par exemple?. En supposant biensur que tes noeuds ne stockent pas non plus de grosse quantité d'information.
Déjà est-ce possible de le quantifier de cette manière?

Pour 50 caractères en moyenne par balise avec texte, 10 Mo ça fait plus de 200000 balises !

Je suis d'accord avec ce qui a été dit précédemment et je me permet de rajouter que les fichiers XML ne sont pas du tout pratiques si l'application considérée doit modifier les données ! Il faut largement mieux avoir un moteur de base de données pour gérer les accès concurrents et les mises à jour transactionnelles (même si, en XML, il y en a heureusement moins souvent besoin).

Enfin, pour des données ne bougeant quasiment pas, le souci est effectivement sur l'obligation de les monter toutes en mémoire (sauf en SAX) ce qui est un peu chaud pour une requête HTTP, tant en délai qu'en espace mémoire. Je pense sincèrement que les performances SQL ne sont jamais terribles mais plutôt régulières tandis que, pour des traitements XML, les performances peuvent être meilleures ou complètement catastrophiques pour du transactionnel : tout dépend de la structure de l'arbre et des parcours demandés.

Personnellement je n'aime pas XQuery parce qu'il n'est pas en XML mais bon...

Merci Alain pour tes remarques constructives.
Je rebondis sur ton aspect gestion de la mémoire :

Citation:

---

Enfin, pour des données ne bougeant quasiment pas, le souci est effectivement sur l'obligation de les monter toutes en mémoire (sauf en SAX) ce qui est un peu chaud pour une requête HTTP, tant en délai qu'en espace mémoire.

---

Je ne comprend pas trop bien ce que tu entend par "monter en mémoire" et le problème avec HTTP. Le parcours d'arbre est-il si gourmand que ca?

"Monter en mémoire" est une expression de vieux comme moi :) qui veut simplement dire charger en mémoire : par l'opération de "parsage", un document XML est représenté en mémoire par toute une structure complexe avec pointeurs et autres ... Tout ça prend un peu de temps, qui doit être proportionnel à la taille, et de la mémoire, selon un facteur que j'imagine entre 4 et 10 ??

Lors du traitement d'une requête HTTP, le thread (ou équivalent) correspondant est naturellement limité à un maximum de temps d'exécution et un maximum d'espace mémoire propre, histoire de permettre aux autres de travailler et de se prémunir des problèmes de bugs ou autres. De plus, le délai d'attente du navigateur est confortable mais l'internaute n'attendra pas forcément aussi longtemps : certains mettent en place des messages d'attente...

Le parcours lui-même n'est pas forcément coûteux même si des traitements un peu complexes peuvent aboutir à des comportements exponentiels : tout semble OK sur quelques balises mais sur des milliers tout explose (pile, mémoire, temps d'exécution,...).

Encore une fois, une base relationnelle est plus régulière en performances mais je maintiens que c'est de l'artillerie lourde pour la plupart des problèmes ! Bien sûr, un SGBD gère lui-même son espace mémoire et celui-ci n'est pas limité comme celui pour traiter une requête HTTP : un SGBD va disposer d'un maximum de cache pour gagner en rapidité de réponse.

Merci beaucoup Alain pour tes reponses précises, je me reveillerai moins bête demain grace à toi. :lol:
Je vais continuer à me documenter sur ce langage et voire ce que c'est XQuery.
Merci beaucoup.