xml vs mysql, performance selon différents besoins

Bonjour à tous.

Je suis sur la phase d'étude d'un projet assimilable à des QCM (questions à choix multiples):
je dois enregistrer les choix des différents utilisateurs pour pouvoir - à une date limite fixée - les analyser pour donner un nombre de points adéquats à chacun, chaque utilisateur pouvant modifier ses choix jusqu'à la date limite, et ainsi en déduire un classement.

Un enregistrement type sera celui-ci => individuX Pays Ville Choix

Mon soucis est de choisir entre un stockage des choix dans une base de données ou bien dans un fichier XML (j'utilise simpleXML). En effet, plusieurs milliers, voir dizaine de milliers (et en théorie pourquoi pas encore plus ^^) de lignes pourraient être inscrites pour chaque QCM (il y aura 1 table ou 1 fichier xml par QCM)

Or, si pour un petit nombre d'entrée, un fichier XML est bien plus performant, je ne sais pas du tout si tel est toujours le cas dès que le fichier augmente sensiblement (et à partir de quel niveau).

De plus, le fait que les choix soient modifiables est à prendre en compte car je n'ai aucune idée des performances de simpleXML pour parcourir tout le fichier jusqu'à trouver le bon individu.

Voilà, vous connaissez ma problématique actuelle et j'aimerais bien avoir vos différents avis.

Merci d'avance.

Signé Sagat

Salut,

En ce qui me concerne je ne poserai même pas la question => DB !!

Faut dire que je ne suis franchement pas un pro de XML (et c'est valable pour tout le reste de ce post ), mais en terme de perfs je suis prêt à parier ma bouteille qu'il n'y a pas photo.
Sauf erreur de ma part le XML sera chargé en mémoire et parcouru intégralement, ... pour 500 lignes on s'en fout un peu, pour 20000 lignes ... heu, ça craint, surtout si tu dois récupérer ce contenu à chaque connexion du membre et qui plus est le modifier (c'est un peu ce que tu dis d'ailleurs).
A propos de ce dernier point (les modifs d'un XML) je trouve cela très lourd en terme de code, de performances, etc ... en comparaison de l'utilisation d'une DB, voire d'un csv.
Je vais une fois de plus me faire des amis, mais SimpleXML et DOM ne sont à mon sens pas suffisamment aboutis.


Dans ce cas peut être, mais je relativiserai un peu si il s'agit de faire des recherches ou des modifications avancées. Un XML ne reste qu'un simple fichier texte, un sgdb est quant à lui optimisé pour une sacrée liste de fonctionnalités, sans commune mesure avec XML niveau flexibilité.

Je pense qu'XML trouve (entre autre) surtout son utilité, et sa puissance, lorsque cela concerne l'interopérabilité entre programmes, langages, ...
Par exemple j'opte pour un fichier XML lorsque que de "grandes" quantités de données "complexes" doivent être traitées côté client (échange PHP<=>JS) C'est bien plus simple qu'une génération de code JS par PHP (surtout avec des librairies telle que JQuery) et ça permet surtout une structuration et une interopérabilité forte (demain je vire PHP au profit d'ASP ou autre, suffit "juste" de générer un XML collant à la DTD)

Bon, j'arrête là, même s'il y aurait sans doute bien plus à dire.
Je ne doute pas que certains viendrons me contredire avec de vrais arguments et à juste titre (ou non )


Cordialement,


Kohntark -

Je te remercie Kohntark pour avoir pris la peine de me répondre si clairement. Et ton point de vue tient largement la route.

En fait, c'est justement en faisant le même raisonnement que toi (ie => la modification d'une seule entrée produirait le chargement et le parcours intégral du fichier XML) que je me suis mis à réfléchir à la question.

Pour ma part, j'ai pris l'habitude d'utiliser des fichiers XML lorsque je connais à l'avance le nombre d'entrée (faible en l'occurrence), mais il est clair qu'à une grande échelle, générer un fichier XML dynamiquement poseraient certains problèmes.

Quant à son utilité en termes d'interopérabilité, XML a en parti été conçu pour ça (en tout cas je l'ai toujours compris comme cela)

Voilà, je te remercie encore pour ton point de vue, et bien sûr si d'autres personnes ont des avis totalement différents qu'ils ne se gênent pas pour m'en faire part.

Merci encore.


Signé Sagat

Salut,

Ca me fait tellement plaisir de trouver sur ce forum une discussion comme ça, que je me sens obligé de répondre... Désolé pour par que je réponde, il fallait ne pas parler d'un sujet intéressant. Et surtout, fallait pas montrer que tu sais un minimum de quoi tu parles...

Bon alors voyons voir...


Rhaaaaaaaaaaaa et y'a même pas moyen de faire preuve de mauvaise foi avec ce post pour gagner la bouteille...


Hélas non, tu as entièrement raison. Ca a déjà été confirmé par Malalam il y a un certain temps déjà, sur une de mes sources. Malalam est quant à lui un pro du XML (qui manie les doigts dans l'nez les transformations XSLT et autres joyeusetés du genre).


Je ne peux que plussoyer, même si ce verbe est un néologisme qui n'a pas encore été approuvé par l'Académie Française.


Je ne peux qu'approuver...
Oui, XML est un simple langage de description de données. Cela signifie qu'il est extrêmement puissant pour stocker des données avec tout un tas d'informations complémentaires. Un analyseur (parser en anglais) devant parcourir le fichier en entier (ne serait-ce que pour s'assurer qu'il est bien formé), il y a forcément une perte de temps. Cela est d'autant plus vrai que le langage utilisé pour l'analyse du fichier est de haut niveau (et PHP est de haut niveau). Tu coderais un analyseur en C, je reverrais probablement ma position, surtout si ton analyseur devait être écrit spécifiquement pour une DTD. Mais PHP n'est pas vraiment fait pour ça...

En réalité, je pense qu'on peut se permettre de stocker un très grand nombre de données dans un fichier XML (cela reste très relatif malgré tout) si le fichier n'a pas vocation à être analysé souvent et s'il n'est utilisé qu'en back-office, cas dans lequel les temps de réponses importent relativement peu (si une opération de maintenance prend 2h, ben elle prend 2h, mais pour l'affichage d'une page, on peut difficilement se permettre de dépasser la demi-seconde pour la génération du document).


Kohntark relativise, pour ma part, j'émet carrément des doutes. En fait, ce qui risque d'être le plus long sur un site web, ce n'est pas l'exécution de la requête, mais le temps de communication entre le serveur web (Apache généralement) et le serveur MySQL (qui sont rarement sur la même machine en environnement de production, comme par exemple sur un serveur dédié).
Là encore, il faut savoir de quoi on parle : de temps de traitement ou de temps total d'exécution. Parce que ça reviendrait à placer le fichier XML sur un serveur distant et y accéder via HTTP (ou, plus généralement, via TCP/IP).
Et comme Kohntark, je pense que le temps de traitement dépend également du traitement lui-même... Si on cherche à accéder à un élément par son ID, ça va assez vite, mais dès qu'on a besoin d'utiliser XPath on dégrade considérablement le temps de traitement (la puissance de XPath résidant dans les possibilités offertes et non les performances en temps).

Dans mon dernier taf, il y a un peu plus de 2 ans, j'avais mis en place un sondage sur le site de la boite. J'avais stocké les données du questionnaire dans un ficheir XML, ce qui me permettait une plus grande souplesse pendant le développement (la personne qui avait commandé la fonctionnalité m'ayant demandé plusieurs fois de rajouter ceci, de faire comme ça, etc). En terme d'affichage, c'était très très satisfaisant (sur un site à forte fréquentation quotidienne). Le fichier XML me permettait de définir tout mon questionnaire : séparation en plusieurs étapes, relations entre les questions/réponses (si on coche "oui" à telle question, on a une autre question qui s'active, etc), et plein de détails que j'ai oublié depuis le temps.
Par contre, j'avais stocké les résultats dans une base de données, parce que c'était ce qu'il y avait de plus performant pour le traitement des résultats : combien ont dit ceci, quel type de personnes a répondu ça, etc.

Voilà ma petite contribution en cette nuit d'insomnie.

--
Neige

Souvent la réponse à votre question se trouve dans la doc. Commencez par là ;)

Bonjour à tous.. enfin un sujet intéressant..
Pour ma part en plus de ce qui a été dit:
1. j'utilise XML pour des données structurés à caractère hiérarchisé. Dans notre cas c'est très light, donc Base de données.
2. par contre, à moins de vouloir mettre de la contrainte d'intégrité partout et ne pas vouloir passer par un ORM, l'expérience m'a un jour montré que si la donnée tendait à être figée et si on reste sur MySQL, il y a mieux qu'innoDB, non.. pas myISAM mais HEAP (testé sur des requetes simples sur plusieurs millions de lignes).
Après tout dépend si tu autorises le retour aux réponses du QCM. mais je pense que ça vaudrait presque le cout de basculer tes tables en HEAP juste si tu es amené à faire de la statistique.
Donc au final et c'est mon point de vue qui n'engage que moi-même: une méthode pour la création et la modification, et une méthode pour la consultation et les stats. Entre les deux un léger travail de transformation, et pourquoi pas sur deux serveurs différents (le plus puissant pour la stat).
S.

Re-bonjour,
je vous remercie de vos constructives participations, c'est très intéressant.

Je me posais beaucoup de questions, certaines sont résolues.

1- Préférer XML pour ce qu'il est: un fichier stockant des données.
Par conséquent, je m'en servirais pour afficher ces données (dans mon cas les questionnaires) et privilégierais Mysql pour le traitement/modification des résultats.

2- J'avais pour à priori qu'une connexion Mysql était bien plus coûteuse (en termes de ressources et de temps de traitement) que l'accès à un fichier XML. Or si vous émettez des doutes, y compris pour des petits fichiers, c'est que ce n'est pas le cas (en tout cas pas systématiquement, faudrait tester au cas par cas).

3- Enfin, je ne connais pas HEAP et vais donc me renseigner sur le sujet. Quand à l'idéal d'utiliser plusieurs serveurs, effectivement c'est une possibilité qui sera étudié attentivement en temps voulu (et surtout adéquat ^^). Mais je ne suis qu'en phase d'étude, et essaie de mettre en place le puzzle avant de me lancer à corps perdu.

Bref, encore merci pour vos avis, j'y vois un peu plus clair.

Signé Sagat

Oh mais alors il en existe des comme toi... C'est surprenant, tu fais partie d'une catégorie en voie d'extinction, il suffit de lire le forum pour s'en rendre compte...

--
Neige

Souvent la réponse à votre question se trouve dans la doc. Commencez par là ;)