IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

XQUERY/SGBD XML Discussion :

XML ou BDR ?


Sujet :

XQUERY/SGBD XML

  1. #1
    Membre averti
    Inscrit en
    Janvier 2007
    Messages
    33
    Détails du profil
    Informations forums :
    Inscription : Janvier 2007
    Messages : 33
    Par défaut 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.

  2. #2
    Expert confirmé
    Avatar de GrandFather
    Inscrit en
    Mai 2004
    Messages
    4 587
    Détails du profil
    Informations personnelles :
    Âge : 55

    Informations forums :
    Inscription : Mai 2004
    Messages : 4 587
    Par défaut
    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.
    FAQ XML
    ------------
    « Le moyen le plus sûr de cacher aux autres les limites de son savoir est de ne jamais les dépasser »
    Giacomo Leopardi

  3. #3
    Membre averti
    Inscrit en
    Janvier 2007
    Messages
    33
    Détails du profil
    Informations forums :
    Inscription : Janvier 2007
    Messages : 33
    Par défaut
    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?

  4. #4
    Membre Expert Avatar de alain.couthures
    Profil pro
    Gérant
    Inscrit en
    Avril 2007
    Messages
    902
    Détails du profil
    Informations personnelles :
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Gérant

    Informations forums :
    Inscription : Avril 2007
    Messages : 902
    Par défaut
    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...

  5. #5
    Membre averti
    Inscrit en
    Janvier 2007
    Messages
    33
    Détails du profil
    Informations forums :
    Inscription : Janvier 2007
    Messages : 33
    Par défaut
    Merci Alain pour tes remarques constructives.
    Je rebondis sur ton aspect gestion de la mémoire :


    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?

  6. #6
    Membre Expert Avatar de alain.couthures
    Profil pro
    Gérant
    Inscrit en
    Avril 2007
    Messages
    902
    Détails du profil
    Informations personnelles :
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Gérant

    Informations forums :
    Inscription : Avril 2007
    Messages : 902
    Par défaut
    "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.

  7. #7
    Membre averti
    Inscrit en
    Janvier 2007
    Messages
    33
    Détails du profil
    Informations forums :
    Inscription : Janvier 2007
    Messages : 33
    Par défaut
    Merci beaucoup Alain pour tes reponses précises, je me reveillerai moins bête demain grace à toi.
    Je vais continuer à me documenter sur ce langage et voire ce que c'est XQuery.
    Merci beaucoup.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. xml -> xsl -> xml
    Par virgile04 dans le forum XSL/XSLT/XPATH
    Réponses: 2
    Dernier message: 10/10/2002, 16h53
  2. Balises HTML dans un fichier XML
    Par Bastet79 dans le forum XML/XSL et SOAP
    Réponses: 12
    Dernier message: 04/09/2002, 15h29
  3. delphi XML / HTML caractéres speciaux !
    Par adem dans le forum EDI
    Réponses: 2
    Dernier message: 29/08/2002, 17h48
  4. Débutant XML
    Par viny dans le forum XML/XSL et SOAP
    Réponses: 8
    Dernier message: 25/07/2002, 12h07
  5. Pas de casse dans les XML
    Par :GREG: dans le forum Composants VCL
    Réponses: 4
    Dernier message: 17/07/2002, 13h51

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo