Performances des fichiers XML/XSL vs SGBD

· Niveau : INTERMÉDIAIRE
· Compatibilité : IE 4+ / NS 6+

Le XML c’est une structure de données qui se compare beaucoup plus à une base de données qu’au HTML. La similitude avec le HTML se résume à l’utilisation de balises. En d’autres mots, vos documents XML ne remplaceront pas vos documents HTML mais plutôt le stockage de vos données. À l’image d’une base de données, un document XML devra être converti en HTML ou en XHTML. Alors l’enjeu, sur le Web, est de savoir s’il faut utiliser le XML ou une base de données. La réponse n’est pas aussi simple. Le XML et la base de données ont tout deux leurs avantages. La question est donc Quand utiliser le XML?

Note, cette série de tutoriels sur le XML s’adresse aux webmestres de sites dynamiques. Rien ici ne s’applique à un site statique, le HTML reste encore aujourd’hui la façon la plus compatible, économique et rapide d’acheminer un document par Internet.

La rapidité du XML
J’utiliserais toujours les bases de données, il n’en reste pas moins qu’une base de données a deux handicapes. Premièrement elle demande énormément de ressources serveur. Deuxièmement c’est long, très long, votre requête doit passer par ADO puis OLEDB ou ODBC, sans parler des DSN... En plus, vous risquez sur un serveur très actif de devoir attendre à la file qu’une connexion se libère. Tout le contraire du XML, qui n’utilise que peu de ressources et surtout plus rapidement. Comparable à la manipulation de fichier texte.

Un simple fichier texte de données structuré
À première vue, la portabilité des données XML semblait la raison de son usage. Mais, pour un programmeur, ça reste un détail, rien de plus facile à faire qu’un petit programme pour exporter des données vers à peu près n’importe quoi! Et d’ailleurs un fichier CSV fera la même chose très bien. C’est donc la rapidité à transmettre des données qui fait du XML un langage de prédilection pour le Web. En d’autres mots, l’avantage du XML réside surtout dans le fait qu’il soit un fichier texte! D’accord ou pas, manipuler un fichier texte est tout simplement beaucoup plus rapide tout en demandant moins de ressource serveur, ce pourquoi je l’utilise!

Exemple : J’ai fait un petit test très simple. Un texte de 300 caractères dans une base de données et dans un document XML. Le temps de réponse est le suivant :

Support	Milliseconde

Base de données	100ms
Document XML	10ms

La puissance et la flexibilité
Rien de nouveau sous le soleil, j’ai toujours utilisé des fichiers texte, pratique et rapide et ce bien avant l’ère du Web. Même le texte que vous lisez présentement (si vous êtes sur les Trucsweb) provient d’un fichier texte. Toujours pour la même raison de rapidité. Ce que le XML apporte de nouveau c’est les outils. Le XSL, XSLT, XSL-FO, XLink, XPointer sans parler des nombreux moteurs (parseurs); Microsoft.XMLDOM, Flash MX etc. Outils qui rendent la manipulation du fichier "texte" XML beaucoup plus agréable que l’utilisation du FSO (FileSystemObject) par exemple.

XML ou SGBD?
Le but étant d’augmenter le temps de réponse pour afficher des données il ne faudrait pas pour autant perdre la capacité de calcul et de recherche d’une base de données. Tout est alors une question de jugement particulièrement basé sur la demande. Plusieurs critères doivent être regardés. La fréquence de la demande, le poids des données, la fréquence de mises-à-jours etc.

Un texte comme celui que vous lisez à de forte chance d’être demandé 20 000 fois d’ici un an, une bonne raison d’optimiser son temps de réponse avec un fichier texte surtout que les mises à jour sont pratiquement nul. Par contre un système de facturation, rarement demandé mais surtout souvent calculé, sera bien plus efficace dans une base de données. À part la portabilité du XML je ne vois pas ici de raison pratique d’utiliser le XML pour stocker de courtes données archivées.

L’objet statique. Bien qu’un menu passablement dynamique puisse être en mémoire, utiliser le XML pour le stocker est une très bonne idée. En demande des millier de fois par jour c’est même une très bonne idée. Par contre si votre menu est tout à fait statique, ce n’est pas la peine. Un bon vieux fichier "include" fera 10 fois mieux le travail. En gros, la génération de page HTML devrait être un bon ménage entre des fichiers imbriqués (include), des données XML, un SGBD et des variables résidentes en mémoire.

Un langage intuitif
Maintenant que le XML à sa place dans un développement Web, il ne faudrait pas négliger le côté travail que cela implique. Une tout autre technique, vos anciens codes risquent de passer à la poubelle.

Côté programmation, le XML n’est pas à la porté de tous. Le plus intuitif des langages, à ma connaissance, à part le Prolog qu’il a d’ailleurs en similitude. On pense le connaître mais il revient toujours nous surprendre. On peut passer des heures à chercher un moyen de déchifrer ou de récupérer une chaîne pour ce rendre compte finalement que la solution est dans un jeu de structure. C’est d’ailleurs là le secret, la structure que nous verrons plus loin. L’analyse structurelle des données n’a jamais été aussi importante qu’avec le XML. La plupart des astuces se retrouveront dans la structure même de vos données. Ça devrait aussi être le cas avec une base de données mais...

Et la mise à jour
Oui, en effet la mise à jour d’un fichier texte même en XML est plus complexe que la gestion d’une base de données. Plus complexe, en fait plus long, plus de lignes de code tout simplement parce qu’il est encore jeune. Mais le principe est le même, ouvrir le fichier, promenade parmi les noeuds (la structure), apporter les modifications et fermeture du fichier. Le XML ne permet de faire de l’édition en tant que telle. La mise à jour peut-être fait de diverses façons, du logiciel d’édition spécialisé au simple "Notepad/simple text". En programmation avec le ASP/PHP/JSP mais aussi en Flash etc. La question sera traitée plus loin notamment en ASP et en Flash.

Voyons toujours un exemple. Imaginons que la page HTML ne contient qu’un texte. D’un côté l’internaute qui visite la page sans devoir utiliser la base de données. Et de l’autre, le Webmestre qui, à l’aide de la base de données, met à jour ses fichiers XML. L’exemple est basé sur un serveur IIS avec ASP et le parseur Microsoft.XMLDOM.

Utilisable dès maintenant
J’ai besoin d’action, de réalité. J’amais je n’aurais adopté le XML s’il ne m’avait aussi apporté satisfaction dans mon travail. Il est fonctionnel sur plusieurs de mes sites. Il se travaille bien. Il est compatible, avec beaucoup d’attention toute fois. Et c’est un langage d’avenir! Déjà compatible Internet Explorer 4+, principalement 5+ et Netscape 6+, demain le XML sera manipulé directement par tous les navigateurs, côté client! C’est dire que vos données, la manipulation XSLT, le format et les styles (CSS) pourront être tout simplement acheminés au navigateur qui se chargera de tout présenter. On ne sauvera pas le monde ni l’énergie mais au moins un CPU refroidira. Reste à faire de bons textes pour la sauver, la planète ;-)

Conclusion
Déjà le XML s’avère très efficace et pratique. À ne surtout pas négliger si vous être un développeur consciencieux. Avec un peu beaucoup de travail on peut même arriver à faire une seule combinaison de fichiers XML/XSLT/XSL tout à fait compatible. Un charmant côté portable et universel mais aussi la possibilité d’utiliser des documents XML de serveurs distants. Sa rapidité à sa complexe simplicité ;-) Bref, un langage fait par et pour le Web.