Note de Zeus : sujet extrait de =>CA<=

Je dis ça rapidement, mais il y a une fonction native dans MySQL 5 qui mériterait une petite exploration : IFNULL() pour optimiser un peu ça en combinaisons avec des jointures externes au lieu de clauses WHERE

Faut éviter... C'est unique à MySQL et si il change après...

Pas tout à fait exact : j'ai utilisé ça pour MySQL 5 sur une grosse appli de commerce en ligne et en cours de route, on nous a remplacé MySQL 5 par Oracle : s'il est vrai que IFNULL ne fonctionne pas avec Oracle, ça ne veut pas dire qu'on ne peut pas utiliser une fonction similaire, de mémoire NVL() ou quelque chose qui ressemble à ça et je n'ai pas du changer le reste de la requête.

N'oubliez pas, les SGBD de ce calibre sont puissants et comportent de nombreuses fonctions natives : elles sont là pour être exploitées. Je vous accorde que c'est du SQL avancé, mais où est le problème ? Suffit de s'y mettre un peu, d'apprendre et d'aller un peu au delà du SELECT *

Tout le monde n'est pas capitaliste
Si tu avais prit PostGreSQL tu ne l'aurait pas eu...

Faut éviter... C'est unique à MySQL et si il change après...

Sûrement pas. Tous les SQL sont des dialectes uniques. Dès que l'on va au-delà du simple SELECT * FROM table, on tombe dans du spécifique.
Juste un exemple : Faut-il donc s'interdire de manipuler les dates dans les bases de données sous le prétexte que la syntaxe est spécifique à chaque base ?

Bien sûr je ne parle pas des types de colonne, de la syntaxe de création d'une table où chaque base à ses options, du champ autoincrémenté de MySQL qui n'existe pas dans d'autres bases, de la syntaxe LIMIT spécifique à MySQL, des procédures stockées, de l'utilisation des majuscules/minuscules dans les noms de champs ou dans les valeurs des champs textes, des tailles et des précisions des champs, des options fulltext ou géographiques, ...

Soit on veut une portabilité de la syntaxe SQL et on passe par les drivers ODBC qui uniformisent (et donc appauvrissent) la syntaxe SQL (et en plus, cette uniformisation n'est pas complète), soit on passe par les drivers natifs et à ce moment-là, on n'a plus la portabilité de SQL.

Tout le monde n'est pas capitaliste
Si tu avais prit PostGreSQL tu ne l'aurait pas eu...

Abstenons-nous de tout esprit de clocher. Celui qui décide, ça reste le client. S'il a fixé son choix sur PostGreSQL, alors c'est très bien, s'il a choisi MySQL, Oracle ou autre chose, c'est tout aussi bien.

Ce qui est donc la conclusion logique, c'est que, comme développeurs, nous avons d'une part le devoir d'écrire un code SQL standard qui s'adaptera sans difficulté à pratiquement n'importe quel SGBD, d'autre part un devoir de conseil auprès justement du client qui n'est pas familier avec tout ceci, ce qu'on ne peut lui reprocher, après tout ce n'est pas forcément son métier, sinon il n'aurait pas besoin de nous, et enfin, c'est un motif pour nous d'utiliser une couche d'abstraction telle que PDO histoire de ne pas devoir tout refaire à chaque fois qu'un changement se produit.

Tout le monde n'est pas capitaliste

Oracle base de données chère, c'était absolument vrai il y a 10 ans, c'était un peu moins vrai il y a 2 ans. Maintenant, un Oracle 11g pour 5 utilisateurs simultanés sur une machine biprocesseur de production, c'est 750 dollars. Et c'est gratuit sur une machine de développement.

comme développeurs, nous avons d'une part le devoir d'écrire un code SQL standard qui s'adaptera sans difficulté à pratiquement n'importe quel SGBD, d'autre part un devoir de conseil auprès justement du client qui n'est pas familier avec tout ceci

Je suis parfaitement d'accord avec le rôle de conseil, mais pas sur le SQL standard. Notre devoir, c'est après analyse des besoins du client, d'exposer les différentes options possibles avec leurs avantages et inconvénients et d'effectuer un choix ensemble. McCall est un peu loin, mais la portabilité du code et l'efficacité sont deux facteurs de qualité tout aussi respectables l'un que l'autre, mais qui sont incompatibles.

On peut donc tout à fait avoir un client qui préfère qu'on utilise à fond les possibilités d'une base et qui sait que s'il veut en changer, ce sera difficile (c'est-à-dire cher) et celui qui joue la prudence et les possibilités de changement. Mon expérience m'a montré qu'en général les premiers partent sur des bases historiques telles qu'Oracle ou SQL Server (Microsoft ou Sybase) tandis que les seconds partent sur du MySQL ou du Postgresql.

Si le client ne connais pas notre travail et qu'il nous laisse les mains libre nous devons utiliser les technologies dans lequel nous somme les plus alaise (je sais pas l'écrire ><).
Je reviendrais là dessus plus tard, en ce qui concerne les couches d'abstraction, en utilisant des fonctions hors de la norme (SQL dans le cas présent) nous perdons une couche d'abstraction et l'application est moins standardisé...
Revenons sur le client, si il est ignard (comme souvent) et qu'il nous dicte notre manière d'agir c'est un peu comme si un fonctionnaire disait à un maçon de faire sa maison avec du carton, nous avons donc le devoir, en tant que professionel de défendre notre point de vue et de convaincre notre client qui n'en sera que plus heureux si il n'y a aucun problème sur ses applications...

PS : MySQL n'est pas un vrai SGBDR au passage

Standard et efficacité ne sont nullement incompatibles. J'ai cité l'exemple que j'ai moi-même vécu l'an dernier, un site de commerce en ligne (auchandirect.fr pour ne pas le nommer) : au départ du projet en janvier 2007, nous étions partis sur MySQL5 : on a quand même eu le nez fin et on a utilisé PDO. Grand bien nous en a pris parce qu'en juin, la direction de AuchanDirect a finalement opté pour Oracle : la bascule s'est faite en environ deux jours à cause justement de l'utilisation de certaines fonctions spécifiques propres à MySQL qu'on a converti pour Oracle. Mais on a pas perdu de temps et on a pas dû tout refaire.

...les plus alaise (je sais pas l'écrire ><).

"à l'aise" tout simplement...

...ignard ...

"ignare"

...nous avons donc le devoir, en tant que professionel de défendre notre point de vue...

Absolument pas d'accord : le point de vue ne doit pas entrer en compte. Ce n'est pas une question d'opinion, c'est une question technique à laquelle on doit donner une réponse technique. Si tel ou tel SGBD est plus approprié qu'un autre pour un besoin précis, alors il faut argumenter ce choix techniquement et non avec des affirmations péremptoires.

...PS : MySQL n'est pas un vrai SGBDR au passage

Cette affirmation par exemple mérite une argumentation un peu plus étoffée
Tu aurais dit ça à l'époque de la version 3.23 où à la rigueur la 4.0, j'aurais pu l'admettre. Poussons même jusqu'à la 4.1. Mais je suis très curieux d'avoir l'explication par rapport à la version 5... Il manque quoi selon toi pour mériter le "R" du SGBDR ?

Je rappel a tout ceux qui vont tenter de saisir l'occasion que c'est n'est pas mes fautes d'orthographes qui font de moi un mauvais programmeur

Donc, moi, j'ai fais un site de dimension modeste pour mon lycé l'année dernière, codé avec PDO et MySQL lorsque le site à grandit j'ai perdu 3 heures à le passer en PostGreSQL et heureusement que j'avais pensé au standard car il y avait plus de 500 requêtes différentes à modifier...

Quand à MySQL...
Il ne gère pas l'intégrité référentiel, MySQL ne gère que les petits volumes avec un faible nombre d'accès, contrairement à l'écrasante majorité des autres systèmes, quasiment aucune optimisations...
"Gérer une base de données n'est pas une chose simple, surtout si on veut bien le faire. MySQL a permis à tout un chacun de s'essayer dans ce domaine, mais pour moi ce n'est pas réellement un SGBDR. Attention il convient parfaitement pour la plupart des sites web, mais ce n'est pas pour rien que SourceForge pour ne citer que lui a fini par abandonner MySQL pour passer à PostGreSQL. Pour ceux qui ont connu ce moment, vous avez connu également la différence considérable de performances : MySQL n'était tout simplement plus capable de gérer une base de données devenue trop grosse et trop complexe. "
http://www.siteduzero.com/tuto-3-20951- ... oisir.html

Voilà d'où ça vient

Certes la structure de gestion ressemble à un SGBDR, mais dans sa programmation pure ce n'en n'est pas un... Il respect peu la norme SQL2003...

Voilà un aperçut

Ha... alors il faudrait m'expliquer comment ils font chez Google. Parce que, pour mémoire, la base de données derrière ce moteur de recherche, c'est du MySQL. Ok, il ont un peu mis les doigts dans le code et apporté des améliorations dont on attend les codes à la fin de cette année. Néanmoins, si MySQL ne permettait pas de gérer les grands volumes de données, Google ne l'utiliserait tout simplement pas du tout.

Quand à MySQL...
Il ne gère pas l'intégrité référentiel...

Absolument faux : il suffit de choisir le moteur approprié : InnoDB fait ça très bien et Falcon le fera également. C'est sur que si tu crées des bases en utilisant MyISAM, c'est mort pour l'intégrité référentielle.
On pourrait aussi parler des transactions : InnoDB est encore une fois la réponse, Falcon fera pareil, MyISAM ne répond pas à cet appel non plus.

Attention avant d'affirmer certaines choses. Certains sites sont fait par des gens qui n'ont pas obligatoirement les connaissances requises pour utiliser certains éléments : un site qui a de gros volumes de données et des montées en charge importantes, ça implique d'avoir un DBA qualifié et compétent. Tous les éditeurs n'ont pas forcément les moyens de se les offrir.

Je vois surtout un truc dans ce sujet : certains avancent des choses comme sainte vérité alors que je doute du recul qu'ils ont dessus.

Pour preuve, voilà l'entête de ta source :

Vous vous apprêtez à lire un tutoriel rédigé par un membre de ce site. Malgré tout le soin que ce membre a pu apporter au tutoriel, nous ne pouvons pas garantir que les informations contenues sur cette page sont exactes à 100%. Merci de garder cela en tête lorsque vous lirez cette page ;o)

@Cyrano
Je ne parle pas de l'efficacité du codage, mais de l'efficacité de l'exécution. Tu as donc privilégié la portabilité en utilisant PDO (excellent choix d'ailleurs).

Tu confirmes d'ailleurs mon expérience des clients qui choisissent MySQL ou Postgresql : le risque d'évoluer vers Oracle ou SQL Server est beaucoup plus grand que lorsque le client choisit d'entrée Oracle ou SQL Server (je n'en ai jamais vu qui décide de migrer d'Oracle vers MySQL). Je nuancerais également avec la taille du client : récemment, j'ai développé un site Web pour une assoc loi 1901 avec un budget de 1000 euros annuel. On a pris MySQL et un hébergement mutualisé : ça m'étonnerait grandement qu'un jour ils passent sous Oracle. Donc pourquoi se priver des fonctions spécifiques MySQL ?

Tant que tu utilises des ordres SQL standard (des SELECT, UPDATE ou INSERT simples), il n'y a aucun souci. Les choses se compliquent avec des requêtes qui utilisent des fonctions ou des requêtes complexes comme celle objet de ce post.
Par exemple, pour résoudre le problème objet de ce thread, on peut tout à fait s'en sortir avec du SQL standard avec une requête sur les villes, puis pour chacune d'entre elle avec une requête de comptage sur les associations et enfin faire le traitement du croisement en PHP.

Donc, encore une fois, je suis nuancé : faire du SQL standard (si tant est que cela veuille dire quelque chose car le noyau commun à tous les dialectes SQL est vraiment très pauvre) pourquoi pas ? Comme toujours lorsqu'il y a un choix, il y a des avantages et des inconvénients.

PS : MySQL n'est pas un vrai SGBDR au passage

Ah bon ? MySQL est un SGBD et il utilise l'algèbre relationnelle.

Je ne voudrais pas paraître désagréable, mais en 1998 on nous a imposé de travailler avec Postgresql. J'espère que la fiabilité et les performances de ce moteur ont été améliorées en 10 ans, parce que c'était une véritable catastrophe : ça plantait une fois par semaine et quand ça plantait on perdait les bases.

Ok, il ont un peu mis les doigts dans le code et apporté des améliorations

J'adors cette phrase
Ils se sont basé sur MySQL mais, à mon avis, ils ont bien modifier 60% du code...

On appel ça gardé l'étiquette pour changer le contenu...

Mais nous, imbles mortels, programmeurs dénué de tout moyen financiers, nous n'avons pas les moyens de nous payer plusieurs dizaine de serveurs...

Je crois que je n'ai pas répondu a toutes les questions, je m'en excuse car je dois aller manger, reposez les moi après

Ils se sont basé sur MySQL mais, à mon avis, ils ont bien modifier 60% du code...

Ça aussi c'est une affirmation totalement gratuite qui ne repose sur absolument rien de concret et qui n'est pas logique non plus.

On ne s'amuse pas à ré-écrire 60% d'une application si elle ne fait pas l'affaire, surtout pas dans le cas de Google. Ils ont les ressources techniques, scientifiques et financières pour se créer une application maison s'ils en ont besoin et ça irait plus vite. MySQL correspondait à leurs besoins pour l'essentiel, et il y a fort à parier qu'ils ont amélioré le moteur qui est derrière les tables ainsi (et surtout) que les problèmes de load-balancing qui doivent être assez monstrueux, on le comprendra aisément.

Quant aux volumes de données, je crois que Google est une référence en la matière : si MySQL fonctionne pour Google avec des quantités aussi énormes et avec la vitesse qu'on leur connaît, les explications que tu donnes à propos du changement de base par le site du Zéro ne tiennent pas la route.

Que tel ou tel SGBD soit plus facile à utiliser peut être un élément de choix, mais l'efficacité dépendra surtout des compétences du DBA : s'il est bon, ça tournera bien, mais si c'est un type qui a marqué DBA sur sa carte de visite mais ne sait pas modéliser correctement une base ni faire une jointure un peu complexe, il finira de toutes façons avec n'importe quel SGBD par se planter. Ce métier (car c'en est un, n'en doute pas une seconde) ne s'improvise pas.