est-ce que tu veux bien nous expliquer comment une requête ramenant 10ko dans une base de 1To avec un critère de recherche (disons: toutes les entités ayant un attribut toto=tata) peut avoir un temps de réponse et une consommation de ressource uniquement fonction du volume de données à ramener ? à part à avoir un index placé précisemment sur le bon attribut et fortement discriminant (c'est-à-dire strictement la même chose qu'avec un sgbdr).
même question avec une expression xpath comme filtre (puisque tu dis "quelle que soit la complexité de la requête"), parce que là j'aimerais bien voir la structure d'index qui permet de résoudre le problème autrement qu'en temps proportionnel à la taille de la base (avec un sgbdr on parle de full scan).
en sql il y a une commande qui s'appelle alter table. le problème est dans le code appelant, mais c'est le même avec une table ou avec un doc xml, si le code appelant ne lit pas le nouvel attribut couleurDesYeux dans l'entité ficheDuPersonnel, l'utilisateur ne sera pas plus content que si c'est une colonne qui n'est pas lue...
pour ton info un sgbdr n'alloue pas la taille max d'un enregistrement à chaque fois qu'on fait un insert dont les 3/4 des colonnes sont à null.
effectivement les bases de données XML ne font que commencer, mais heureusement demain le ciel sera plus bleu et l'herbe plus verte grâce aux bases XML.
enfin en tout cas c'est comme tout ce qui salope le SI des clients et crée de l'entropie (eai, sgbdo...), après il faut faire les poubelles et ça me garantie du travail à vie sur plusieurs générations... mes futurs arrières-petits-enfants se joignent à moi pour dire merci à XML, dieu de la fertilité dans le panthéon de l'informaticien.
(je réagis vivement à "base de données XML", je ne nie pas l'utilité de certains usages de XML)
[^] # Re: Ne vous perdez pas en route!
Posté par DerekSagan . En réponse au sondage XML est. Évalué à 7.
même question avec une expression xpath comme filtre (puisque tu dis "quelle que soit la complexité de la requête"), parce que là j'aimerais bien voir la structure d'index qui permet de résoudre le problème autrement qu'en temps proportionnel à la taille de la base (avec un sgbdr on parle de full scan).
en sql il y a une commande qui s'appelle alter table. le problème est dans le code appelant, mais c'est le même avec une table ou avec un doc xml, si le code appelant ne lit pas le nouvel attribut couleurDesYeux dans l'entité ficheDuPersonnel, l'utilisateur ne sera pas plus content que si c'est une colonne qui n'est pas lue...
pour ton info un sgbdr n'alloue pas la taille max d'un enregistrement à chaque fois qu'on fait un insert dont les 3/4 des colonnes sont à null.
effectivement les bases de données XML ne font que commencer, mais heureusement demain le ciel sera plus bleu et l'herbe plus verte grâce aux bases XML.
enfin en tout cas c'est comme tout ce qui salope le SI des clients et crée de l'entropie (eai, sgbdo...), après il faut faire les poubelles et ça me garantie du travail à vie sur plusieurs générations... mes futurs arrières-petits-enfants se joignent à moi pour dire merci à XML, dieu de la fertilité dans le panthéon de l'informaticien.
(je réagis vivement à "base de données XML", je ne nie pas l'utilité de certains usages de XML)