J'ai dû être un peu trop cryptique, donc je vais essayer de mieux m'expliquer : dans une base de données orientée XML, les données peuvent très bien être traduites en interne par des structures de données tout à fait « binaires » : il faut juste qu'il existe une DTD ou un schéma XML disponibles (et comme on parle de gros documents, il serait étonnant que ça n'existe pas).
L'indexation de documents XML et de leur contenu, ça existe déjà depuis un moment. Et puis, rien n'empêche au moment de l'analyse d'un fichier importé en XML de le forcer un peu à avoir une certaine gueule pour faciliter les accès dessus.
« XML ça reste du eXtended Markup Language si je ne me gourre pas - et c'est juste une normalisation du stockage "raw". »
Je ne vois pas ce que tu veux dire par là. Les SGBD/XML ont le même objectif que les SGBD/R : permettre la persistance des données. Et ne t'en déplaise, il existe déjà quelques systèmes qui permettent autre chose qu'un bête export de tables d'un modèle relationnel vers du XML (sinon, à la limite, autant exporter en CSV).
Le besoin de ce genre de SGBD vient entre autres de professions où les critères pour classifier les données sont changeants. Par exemple, une expérience faite par un labo en bio ou en chimie, et qui coûte cher - donc pas possible de recommencer tous les jours - aura tout à gagner à être stockée dans une base avec un langage semi-structuré (par ex. XML ;-) ), car au fur et à mesure qu'on aura besoin de rajouter des critères pour analyser les résultats, on pourra. Alors qu'avec un SGBD/R Classique, une fois le schéma réalisé, rajouter une colonne dans une table alors que la base est déjà en train d'être exploitée tient de la gageure.
« Après, avec une spécification de type de document (DTD & Co) on précise ce qui est acceptable pour un usage. »
Non. Avec une DTD ou un schéma XML, tu *types* ton document, et c'est ce qui fait toute la différence : on passe d'un bête fichier texte « plat » (et donc autant chercher à grands coups de regexps dessus) vers un document semi-structuré, un arbre, dont les noeuds sont ordonnés (oui, je me répète), étiquetés, et qui correspondent à des types. Et quand on a un type, on peut déjà faire tout un tas de choses.
Par exemple (on sait bien sûr aussi faire dans les SGBD/R) :
<!ELEMENT adresse (rue,zipcode,ville,pays)>
<!ELEMENT rue (#PCDATA)>
<!ELEMENT zipcode (#PCDATA)>
<!ELEMENT ville (#PCDATA)>
<!ELEMENT pays (#PCDATA)>
Bon ben, si j'essaie maintenant d'interroger ma base de personnes en demandant des trucs du genre
for $x in doc("mes_personnes.xml")/identite/adresse return $x/rue
Parce que la base connaît le type des données, elle saura inférer toute seule comme une grande que l'adresse ne fait pas partie du type « identité », et la requête renverra vide.
Des choses comme ça, on sait très bien faire, et le langage XQuery est au moins aussi puissant que SQL (c'est un peu normal), voire plus.
[^] # Re: Stockage des données...
Posté par lasher . En réponse à la dépêche Sortie de Tellico 1.2. Évalué à 2.
L'indexation de documents XML et de leur contenu, ça existe déjà depuis un moment. Et puis, rien n'empêche au moment de l'analyse d'un fichier importé en XML de le forcer un peu à avoir une certaine gueule pour faciliter les accès dessus.
« XML ça reste du eXtended Markup Language si je ne me gourre pas - et c'est juste une normalisation du stockage "raw". »
Je ne vois pas ce que tu veux dire par là. Les SGBD/XML ont le même objectif que les SGBD/R : permettre la persistance des données. Et ne t'en déplaise, il existe déjà quelques systèmes qui permettent autre chose qu'un bête export de tables d'un modèle relationnel vers du XML (sinon, à la limite, autant exporter en CSV).
Le besoin de ce genre de SGBD vient entre autres de professions où les critères pour classifier les données sont changeants. Par exemple, une expérience faite par un labo en bio ou en chimie, et qui coûte cher - donc pas possible de recommencer tous les jours - aura tout à gagner à être stockée dans une base avec un langage semi-structuré (par ex. XML ;-) ), car au fur et à mesure qu'on aura besoin de rajouter des critères pour analyser les résultats, on pourra. Alors qu'avec un SGBD/R Classique, une fois le schéma réalisé, rajouter une colonne dans une table alors que la base est déjà en train d'être exploitée tient de la gageure.
« Après, avec une spécification de type de document (DTD & Co) on précise ce qui est acceptable pour un usage. »
Non. Avec une DTD ou un schéma XML, tu *types* ton document, et c'est ce qui fait toute la différence : on passe d'un bête fichier texte « plat » (et donc autant chercher à grands coups de regexps dessus) vers un document semi-structuré, un arbre, dont les noeuds sont ordonnés (oui, je me répète), étiquetés, et qui correspondent à des types. Et quand on a un type, on peut déjà faire tout un tas de choses.
Par exemple (on sait bien sûr aussi faire dans les SGBD/R) :
Bon ben, si j'essaie maintenant d'interroger ma base de personnes en demandant des trucs du genre
Parce que la base connaît le type des données, elle saura inférer toute seule comme une grande que l'adresse ne fait pas partie du type « identité », et la requête renverra vide.
Des choses comme ça, on sait très bien faire, et le langage XQuery est au moins aussi puissant que SQL (c'est un peu normal), voire plus.