Question théorique
Bonjour,

J'ai vu un site complètement géré en xml, où la mise à jour se fait par édition des fichiers xml. (le front office est en flash)

Pour vous c'est quand la limite d'utilisation xml ou base de donnée?

Pour moi, l'utilisation du xml sous forme de fichier ce serait uniquement quelques éléments d'interfaces, par exemple les langues ...


Et vous ?? des avis de pures web-développeurs ou designer?


je pense que la taille du site à peu d'incidence sur la méthode employée, meme si souvent les "petits" site sont gérés uniquement avec du xml (ou meme des fichiers textes si si) et les gros sites gérés en bdd.

Il y a surement une raison mais moi j'affectionne bien l'amfphp (flash + bdd directe sans passer par xml)

C'est sur qu'un fichier XML ou fichier type ini pour la configuration c'est cool et aussi efficace que de stocker dans une BDD (accéder au système de fichiers est plus rapide qu'un accès BDD) mais il faut prendre un minimum de précaution si tu veux pas qu'un utilisateur lambda ait accès direct au fichier.

Si le contenu est important et change souvent j'utiliserais une BDD avec système de cache. Je ne ferais jamais un forum en XML ou CSV par exemple.

J'ai bossé sur un site à fort trafic qui avait beaucoup de produits à vendre et qui demandait beaucoup de ressources serveur (CPU + BDD). Le client nous envoyait les produits par XML (fichier de 50Mo), on les mettait en base et on a mis en place un système de cache. Les pages produits étaient générées automatiquement par un cron et stockées en .htm.
Le stock ne changeant qu'une fois par jour, on vidait et régénérait le cache dans la nuit et zou.
Pour ce même site comportant plusieurs langues les fichiers de langue étaient en CSV quand on les éditait et on générait ensuite un fichier PHP contenant un tableau (clé = mot à traduire et valeur = traduction) de langues en PHP basé sur ce CSV. Un include de ce fichier et on avait tout ce qu'il fallait super rapidos.

Donc il n'y a pas de méthode magique, c'est au cas par cas mais en gros vaut mieux éviter de traiter à la volée des fichiers volumineux car ça prend du CPU et de la bande passante pour rien.

Les gros sites gérés par des BDD ? Pas uniquement. Les site à fort trafic il y a forcément un système de cache.

Pour un site à trafic moyen, on peut imaginer une BDD à partir de laquelle on génère des XML coté back office. Ensuite le front office traite les fichiers XML. Pourquoi adopter ce type d'architecture ?
1 - Une transaction avec un SGBD est lente, le temps de la connexion, le temps d'exécution de la requête...
2 - Le nombre de connexion simultanées à une base est limitée très souvent

Donc le XML permet un gain de performance, économise les ressources, etc. Après, c'est vrai qu'il faut le parser à chaque fois le XML... Donc les performances peuvent encore être améliorées avec un système de cache comme l'explique mcfly. Par contre le cache, c'est plus difficile à gérer cote back office... Je me suis pas encore penché sur ce genre d'archi.

Voilà ma vision des choses. Par contre, on ne peut pas générer directement du flash, donc utilisation de fichiers XML.

Le XML est prévu pour structurer tout type de données, pas que un menu ou je ne sais quoi. Même le XHTML est du XML... ^^'

Merci, je vois mieux les différentes situations.

Ishiro > pour le système de cache on lançait un cron qui visitait tout le site à 1h ou 2h du mat' et générait les pages en .htm qui étaient ensuite inclues par PHP.
Il y a aussi des solutions de cache de code (opcode) qui divisent par 10 (voire beaucoup plus) le CPU nécessaire (utilisé par Facebook par exemple).

Sinon avec les extensions qui vont bien on peut générer du Flash à la volée. ;)

Ah ouais, des include quand même...