Xml vs mysql, performance selon différents besoins
sagat06
Messages postés
166
Date d'inscription
mercredi 27 juin 2007
Statut
Membre
Dernière intervention
31 mars 2014
-
13 oct. 2010 à 16:51
neigedhiver Messages postés 2480 Date d'inscription jeudi 30 novembre 2006 Statut Membre Dernière intervention 14 janvier 2011 - 14 oct. 2010 à 17:14
neigedhiver Messages postés 2480 Date d'inscription jeudi 30 novembre 2006 Statut Membre Dernière intervention 14 janvier 2011 - 14 oct. 2010 à 17:14
A voir également:
- Plussoyer académie française
- Créer un utilisateur mysql - Conseils pratiques -PHP
- Foreach php mysql ✓ - Forum PHP
- Schema xml - Conseils pratiques -Visual Basic / VB.NET
- Mysql date - Forum PHP
- Code source formulaire d'inscription php mysql - Forum PHP
6 réponses
kohntark
Messages postés
3705
Date d'inscription
lundi 5 juillet 2004
Statut
Membre
Dernière intervention
27 avril 2012
30
13 oct. 2010 à 19:18
13 oct. 2010 à 19:18
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 -
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.
Or, si pour un petit nombre d'entrée, un fichier XML est bien plus performant [..]
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 -
sagat06
Messages postés
166
Date d'inscription
mercredi 27 juin 2007
Statut
Membre
Dernière intervention
31 mars 2014
1
13 oct. 2010 à 21:10
13 oct. 2010 à 21:10
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
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
neigedhiver
Messages postés
2480
Date d'inscription
jeudi 30 novembre 2006
Statut
Membre
Dernière intervention
14 janvier 2011
19
14 oct. 2010 à 03:08
14 oct. 2010 à 03:08
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...
[quote=Kohntark]je suis prêt à parier ma bouteille/quote
Rhaaaaaaaaaaaa et y'a même pas moyen de faire preuve de mauvaise foi avec ce post pour gagner la bouteille...
[quote=Kohntark]Sauf erreur de ma part le XML sera chargé en mémoire et parcouru intégralement/quote
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).
[quote=Kohntark]pour 500 lignes on s'en fout un peu, pour 20000 lignes/quote
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.
[quote=Kohntark]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é/quote
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à ;)
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...
[quote=Kohntark]je suis prêt à parier ma bouteille/quote
Rhaaaaaaaaaaaa et y'a même pas moyen de faire preuve de mauvaise foi avec ce post pour gagner la bouteille...
[quote=Kohntark]Sauf erreur de ma part le XML sera chargé en mémoire et parcouru intégralement/quote
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).
[quote=Kohntark]pour 500 lignes on s'en fout un peu, pour 20000 lignes/quote
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.
[quote=Kohntark]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é/quote
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).
Or, si pour un petit nombre d'entrée, un fichier XML est bien plus performant [..]
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à ;)
syndrael
Messages postés
2378
Date d'inscription
lundi 4 février 2002
Statut
Membre
Dernière intervention
29 décembre 2012
20
14 oct. 2010 à 08:24
14 oct. 2010 à 08:24
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.
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.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
sagat06
Messages postés
166
Date d'inscription
mercredi 27 juin 2007
Statut
Membre
Dernière intervention
31 mars 2014
1
14 oct. 2010 à 15:54
14 oct. 2010 à 15:54
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
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
neigedhiver
Messages postés
2480
Date d'inscription
jeudi 30 novembre 2006
Statut
Membre
Dernière intervention
14 janvier 2011
19
14 oct. 2010 à 17:14
14 oct. 2010 à 17:14
Mais je ne suis qu'en phase d'étude, et essaie de mettre en place le puzzle avant de me lancer à corps perdu.
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à ;)
