Portekoi Posté 24 Août 2006 Posté 24 Août 2006 Personnellement, j'utilise très peu les BDD.Les avantages à mes yeux à ne pas utiliser MySql sont : - L'exécution est bien plus rapide - les moyens mis en oeuvre peuvent être optimisés - on a la maîtrise de 100% du code - maintenance, sauvegardes et sécurité sont plus faciles à assurer - l'hébergement est bien plus simple (le talon d'Achille des mutualisés est MySql) 1 - Bien plus rapide? Non, je ne suis pas d'accord avec cet argument. Si tu dois prendre UN enregistrement sur 1 Millions (comme un gros forum) lequel sera plus rapide? 2 - Pareil avec Mysql et encore plus facilement grâce au Sql. Des index pour un fichier, jamais vu encore (sauf en DB2 mais c'est une BDD ou les tables s'appellent fichier) 3 - Pareil en SQL 4 - Pareil aussi 5 - La majorité des hébergeurs proposent Mysql. Il vaut mieux 100Mo de données en BDD que 100Mo de données en fichier surtout sur un petit hébergement. Les inconvénients sont surtout qu'il ne faut pas avoir peur de programmer et que la maintenance est plus difficilement transmissible (s'il y a des gros volumes de données, parce que sinon ce n'est pas un problème et quiconque a eu à reprendre des applis MySql écrites par d'autres savent que tout n'est pas toujours rose). Idem en Sql, il ne faut avoir peur de programmer. Pour les applis 'pas roses', "quiconque a eu à reprendre des applis en fichiers écrites par d'autres savent que tout n'est pas toujours bleu". Autrement dis, une developpeur qui ce débrouille mal en Sql en fera tout autant en Fichier. Ceci dit, je ne cherche à convaincre personne : certains vont ouvrir une DBB pour incrémenter un compteur de visites... MySql a le gros avantage d'être accessible à un grand nombre de webmasters/programmeurs en offrant un pseudo-language très performant et facile à mettre en oeuvre. C'est normal qu'il se soit imposé et il est certainement là pour longtemps encore. Mais, en informatique, il n'y a rarement qu'une seule façon de faire les choses... Concernant le "pseudo-langage", j'espère que tu ne parles pas du Sql. Et en informatique il n'y a rarement qu'une seule façon de voir les choses... Portekoi
destroyedlolo Posté 24 Août 2006 Posté 24 Août 2006 Hehe, je ne vais pas repondre sur les arguments car je l'ai deja fait et ... nous tournons en rond Et en informatique il n'y a rarement qu'une seule façon de voir les choses... Portekoi ... mais voila une conclusion qui me plait bien
Remi Posté 24 Août 2006 Posté 24 Août 2006 Quand je parlais de "pseudo-langage", il n'y avait pas une once de mésestime dans mon esprit : C'était simplement une nuance par rapport aux "langages complets" comme Pascal, C, PHP. Le terme n'était visiblement pas idéal car il peut être mal interprété...
stever34 Posté 24 Août 2006 Auteur Posté 24 Août 2006 Bon ben meme si je suis pas un pro, au moins je vois que je me pose les bonnes question avant de me lancer tete béssée dans mon livre
destroyedlolo Posté 24 Août 2006 Posté 24 Août 2006 Bon ben meme si je suis pas un pro, au moins je vois que je me pose les bonnes question avant de me lancer tete béssée dans mon livre Ouai, de toute facon, tu ne peux qu'y gagner a essayer. Et lorsque tu auras a faire quelques choses, tu vera par toi-meme ce qu'il te semble le plus judicieux Bye Lolo
NorSeb Posté 24 Août 2006 Posté 24 Août 2006 Bonjour, N'empèche que pour gérer des données c'est à dire des ajouts, des suppressions, des modifications, des sélection avec des paramètres tels que des tris, gérer les transactions, les collisions ou autres "joyeusetés" de ce genre je ne vois vraiment pas comment un système de fichiers "fait maison" pourrait faire mieux qu'un logiciel spécialisé... même Mysql. Pour gérer 5000 photos, je préfère 100 fois un SGBD® à un système de fichier... Je suis sur d'en avoir sous le coude (car qui peut le plus, peut le moins) en cas de demande de fonctionnalités supplémentaires par exemple. Quant à l'argument des ressources (espace ou processeur) c'est, pour moi, un faux problème à l'heure actuelle. Il y a 20 ans, quand on payait 50 000 pour 20Mo ok ! Mais j'ai entendu une pub à midi pour DD de 400Go pour 159 euros ! Bon ben meme si je suis pas un pro, au moins je vois que je me pose les bonnes question avant de me lancer tete béssée dans mon livre Tu l'a commencé ton livre ? Parce que vu le nombre de questions que tu as posé depuis ton arrivé sur le Hub, tu n'a pas du avancer des masses
Yhann Posté 26 Août 2006 Posté 26 Août 2006 Bonjour à toutes et tous. Il s'agit de mon premier post : je suis tombé sur ce sujet par hasard, et n'ai pas résisté à l'envie de doner mon avis. Ce dernier vaut ce qu'il vaut, mais s'appuit maintenant sur 10 années d'expériences en développement multimédia, dont le web avec PHP. Pour moi, une base de données n'est absolument pas toujours nécessaires, et comme il l'a été dit, sur les hébergement mutualisés, c'est bien les accès MySQl qui sont responsables des lenteurs ressenties lors de la consultation d'un site, sans parler des cas extrêmes, où le serveur MySQL "tombe". L'emploi d'une base de données est justifiée dans les cas que vous citez, et notamment : - quantité impoprtante de données à pouvoir traiter selon différents paramètres - évolutivité - nécessité de gérer les accès concurents Mais l'emploi d'une base de données ne dispense pas de placer en cache (dans des fichiers textes) les pages à afficher. C'est rarement pratiqué, et pourtant, je vous assure que le gain est énorme. Mais bon, ce n'est pas le sujet et les sceptiques trouveront de nombreux benchs sur internet pour s'en persuader. Je tenais à décrire des exemples simples, qui ne devrait pas employer une BDD. Sites modestes, avec un backoffice mono-utilisateur. Sur un site dont l'arborescence est statique, vous placez un édito sur la page d'accueil. Beaucoup emploie MySQL pour cela, alors qu'un fichier texte sera bien plus performant (page s'affichant bien plus vite). La fréquence des mises à jour est faible (moins de 1 fois par jour). Autre exemple, une galerie d'images, avec photos légendées. galerie simple, quelques rubriques à gérer... Dans php, vous utilisez un array tout simple, avec le nom de la rubrique, le fichier et sa légende. Eventuellement un array par rubrique. Vous sérialisez l'array dans un fichier texte. Vous récupérer directement cet array lors de l'affichage. Quel gain de temps, et de ressources. Vous pouvez toujours affirmer que le traitement php est lent, je vous assure, encore une fois, que rien n'est plus lent qu'un accès à MySQL sur un hébergement mutualisé. C'est vraiment le maillon faible. On ne parle pas içi d'espaces disque, mais bien de ressources. Dans l'exemple ci-dessus, j'utiliserai une BDD si je dois gérer des centaines de photos, et pouvoir effectuer des recherches sur leur légendes. Dans les autres cas, jamais je n'employerai une BDD. Attention, cela est valable pour des besoins modestes, avec une évolutivité limitée. Maintenant, si du jour au lendemain, je dois gérer 100000 photos, ce n'est aucunement un soucis. D'une part, cela aurait sûrement été plus ou moins prévu, et dans ce cas, j'aurais utilisé dès le départ une BDD (avec l'emploi de caches, toujours), et d'autre part, quoi de plus simple que de récupérer son array et de remplir une BDD. On ne peut pas dire que dans un tel cas, le passage des fichiers textes à une BDD soit si handicapant que cela, pour peu que l'on maîtrise la programmation et que l'on sache faire des "moulinettes". Si je devais résumer, je dirai que les BDD ont été faites à l'origine pour traiter des besoins spécifiques. Mais la démocratisation de MySQL chez les hébergeurs ont fait que tout le monde utilise une BDD, sans forcément se demander pourquoi. Beaucoup ne connaissent d'ailleurs pas les fonctions php permettant la lecture/écriture de fichiers textes, alors qu'ils savent insérer des données dans une table ! Je rapelle aussi que sqLite est une BDD pouvant être utilisée avec PHP5, et que sur des applications "moyennes", elle se révèle plus rapide que MySQL. Et oui, elle utilise des fichiers plats... A+ Yhann
Portekoi Posté 26 Août 2006 Posté 26 Août 2006 Bonjour, Voici un petit lien fort intéressant : http://fr.wikipedia.org/wiki/SQLite Pour ma part, ne pas pouvoir altérer une table, ne pas pouvoir gérer des index, ne pas pouvoir faire de jointure, ca reste une solution sacrément limitée. Maintenant, concernant la gestion d'une galerie de 100 000 Photos créées à la base avec un fichier plat, c'est tout de même difficile de dire à son patron : "Attendez, je dois faire des "moulinettes" parce que là, je peux pas implémenter de moteur de recherche." Je pense pas que cela lui fera plaisir. Donc, comme je l'ai dis plus haut, avec mes 8 ans d'exprérience, une BDD n'est pas toujours justifé mais lorsqu'il y a un besoin d'évolutivité ou d'implémentation, cela reste la solution la plus simple à mettre en place. De plus, une BDD n'est pas incompatible avec un systeme de cache. En voyant un SPIP tourné et paramétré correctement, cela reste une très bonne solution. Bonne Journée. Portekoi
Yhann Posté 26 Août 2006 Posté 26 Août 2006 Salut, Pour ma part, ne pas pouvoir altérer une table, ne pas pouvoir gérer des index, ne pas pouvoir faire de jointure, ca reste une solution sacrément limitée. Oui, sauf dans les cas où la gestion d'index et l'emploi de jointure est inutile... Maintenant, concernant la gestion d'une galerie de 100 000 Photos créées à la base avec un fichier plat, c'est tout de même difficile de dire à son patron : "Attendez, je dois faire des "moulinettes" parce que là, je peux pas implémenter de moteur de recherche." Je ne parle pas d'une galerie de 100 000 photos, mais d'une galerie devant évoluer vers un nombre de la sorte. Franchement, tu n'es même pas obligé de le dire à ton patron ! Récupérer un array et remplir des tables, c'est quand même pas long ! Donc, comme je l'ai dis plus haut, avec mes 8 ans d'exprérience, une BDD n'est pas toujours justifé mais lorsqu'il y a un besoin d'évolutivité ou d'implémentation, cela reste la solution la plus simple à mettre en place. On est bien d'accord, et c'est exactement ce que je disais. Là où je ne suis pas d'accord avec les "pro-bdd", c'est lorsqu'ils veulent utiliser une BDD sans même se demander pourquoi. Quand l'emploi d'une solution procure un avantage, pas de problème. Dans les exemples que je cite, l'emploi d'une BDD ne procure aucun avantage, c'est tout le contraire. Pour beaucoup, l'emploi d'une BDD n'est pas réfléchit, ou justifié par le côté technique "ouais, j'utilise une BDD...." Mais comme je l'ai expliqué, c'est bien la démocratisation de MySQL et la facilité de prise en charge via php qui on engendrés un tel phénomène. Pourtant, les fichiers textes ont leurs avantages (je ne reviens pas dessus, c'est expliqué plus haut) et ceux-ci ont été injustement délaissés, souvent au sacrifice de la performance, ce qui est un comble ! Beaucoup de jeunes développeurs ne voit la gestion de données que par une BDD, alors qu'il faut savoir mesurer l'utilité réelle d'une telle solution, qui n'est pas adaptées à toutes les problématiques. De plus, une BDD n'est pas incompatible avec un systeme de cache. En voyant un SPIP tourné et paramétré correctement, cela reste une très bonne solution. C'est bien ce que je disais aussi. A+ Yhann.
Remi Posté 26 Août 2006 Posté 26 Août 2006 Pour beaucoup, l'emploi d'une BDD n'est pas réfléchit, ou justifié par le côté technique Oui, je pense que le problème est surtout là : beaucoup de (jeunes) développeurs ignorent tout simplement qu'il existe une alternative aux BDD ou, s'ils savent confusément qu'il est possible d'utiliser des fichiers, ils sont persuadés qu'il s'agit d'une méthode archaïque qui ne peut donc qu'être bien plus lente et sans évolution possible. Mais comme je l'ai expliqué, c'est bien la démocratisation de MySQL et la facilité de prise en charge via php qui on engendrés un tel phénomène. En même temps, c'est ce genre de démocratisation qui a permis l'explosion de l'informatique personnelle depuis 20 ans. Si MySQL n'avait pas apporté un language de haut-niveau facilement assimilable pour permettre stockage et manipulation de données, nous n'aurions pas eu la prolifération des sites internet que nous avons depuis une petite dizaine d'années.
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant