Fusion Oracle-Sun : Widenius fait appel de la décision de Bruxelles, Chine et Russie entrent dans la danse

**Lyche** · 10/12/2009, 14h31

On t'a jamais appris ça durant tes études "un bon développeur est un développeur flemmard" MySQL répond à ça parfaitement. C'est un SGBD de flemmard, pour les flemmards. Sauf qu'il faut être un minimum "intelligent" dans sa flemmardise et ne pas faire comme tous les autres parce qu'ils le font. Combien de fois par jour je corrige des personnes qui demandent "est-ce que c'est bien de faire comme ça". Non, c'est 9 fois sur 10 pas bon, ce sont des techniques employées uniquement par les développeurs php/MySQL parce que leur sgbd leur permet de le faire et que ça ne devrait pas pouvoir se faire. (j'ai pas d'exemples particuliers en tête, mais vraiment, MySQL n'est pas un bon SGBD. (Et j'ai travaillé suffisamment longtemps avec pour me permettre de le dire.)
Edit : Il y a une chose que je ne nie pas en revanche. Ce sont les évolutions, dans le très bon sens du terme, qu'a connu MySQL c'est 5 dernières années.

**berceker united** · 10/12/2009, 14h35

Envoyé par Lyche

L'injection SQL, c'est pas au SGBD de le gérer, mais au développeur. Il y a des centaines de façon de contrer du SQL Injection.
En ce qui concerne les failles, la plus dangereuse pour moi, c'est une faille inhérente à la conception du protocole TCP (qui est quand même la base de beaucoup de choses sur le web) C'est qu'il n'y a aucun système de sécurité

C'est un protocole inventé il y a 40ans pour des besoins privés et la nécessité de le protégé n'a pas été jugée utile. Maintenant, lorsque tu arrives au niveau de la couche TCP, tu peux faire tout ce que tu veux, prendre des données durant leur flux de transfert et les modifier ou même les supprimer complètement. Tu peux accessoirement passer outre le système de protection du http puisque tu es situé à un niveau supérieur et donc contourner tous les systèmes mis en place par MySQL.
Pour ce qui concerne les autres, à ce que je sache, il n'y a pas beaucoup de sgbd dont le système d'interrogation, par défaut, des tables est une adresse web que tu tapes pour retrouver wamp ou autres serveur de gestion MySQL.
pour accéder à ma bdd SQL Server, j'utilise un outil adapté, spécialisé qui se trouve sur la machine. jamais de "http://localhost/myadmin/".
Il y a d'autres solutions à MySQL, FireBird en fait partie et la gestion de la sécurité sur FireBird est incomparable à MySQL pour des temps de réponse souvent supérieurs.
Et je n'ai jamais comparé SQL Server à MySQL, c'est une aberration sans nom. Je dis juste que MySQL est à oublié au profits d'autres SGB plus performants et plus sécurisés. (Hors SQL Server/Oracle/..)

Oui ben qu'il y ait des outils pour interroger une base, il faut pas s'en prendre à Mysql mais au hébergeurs qui le propose.
Mais j'ai l'impression que tu confonds beaucoup de chose qu'en au différent type d'utilisateur.
Celui qui utilise SQLServer est déjà un utilisateur un peut avancé parce qu'il y a fait un chois précis. La plupart des utilisateurs qui utilise Mysql l'utilise parce qu'il est proposé par les hébergeurs. Pourquoi leurs proposer SQLServer si c'est pour pas l'utiliser. Et je sais pas si tu te rend compte mais SQLServer n'est pas donné pour l'utiliser et si nous suivons ton raisonnement il faudrait utiliser un serveur dédier obligatoirement et que l'utilisateur doit créer son outil directement pour pouvoir gérer ses données.
Il faut savoir proposer les bons outils en fonction de l'utilisation.
Que cela ne te plaise Mysql est le moteur de base de données qui à permit de rendre la conception des sites internet plus accessible.

**Fallen_Leaf** · 10/12/2009, 14h41

Envoyé par Lyche

L'injection SQL, c'est pas au SGBD de le gérer, mais au développeur. Il y a des centaines de façon de contrer du SQL Injection.
En ce qui concerne les failles, la plus dangereuse pour moi, c'est une faille inhérente à la conception du protocole TCP (qui est quand même la base de beaucoup de choses sur le web) C'est qu'il n'y a aucun système de sécurité

C'est un protocole inventé il y a 40ans pour des besoins privés et la nécessité de le protégé n'a pas été jugée utile. Maintenant, lorsque tu arrives au niveau de la couche TCP, tu peux faire tout ce que tu veux, prendre des données durant leur flux de transfert et les modifier ou même les supprimer complètement. Tu peux accessoirement passer outre le système de protection du http puisque tu es situé à un niveau supérieur et donc contourner tous les systèmes mis en place par MySQL.
Pour ce qui concerne les autres, à ce que je sache, il n'y a pas beaucoup de sgbd dont le système d'interrogation, par défaut, des tables est une adresse web que tu tapes pour retrouver wamp ou autres serveur de gestion MySQL.
pour accéder à ma bdd SQL Server, j'utilise un outil adapté, spécialisé qui se trouve sur la machine. jamais de "http://localhost/myadmin/".
Il y a d'autres solutions à MySQL, FireBird en fait partie et la gestion de la sécurité sur FireBird est incomparable à MySQL pour des temps de réponse souvent supérieurs.
Et je n'ai jamais comparé SQL Server à MySQL, c'est une aberration sans nom. Je dis juste que MySQL est à oublié au profits d'autres SGB plus performants et plus sécurisés. (Hors SQL Server/Oracle/..)

Le "/myadmin" n'est pas inhérent à MySQL. C'est une installation complémentaire, nullement obligatoire (enfin dans le temps en tout cas c'était comme ça). Et les outils d'interrogation via navigateur existe aussi pour SQL Server ...
Ceci étant, MySQL répond très bien à un type de besoin. Après, la manière dont il est utilisé dans tel ou tel contexte, certes c'est (souvent) parfois affreux pour qui s'y connait un peu en BD. Mais, dans le monde professionnel, j'ai vu tellement d'horreurs sur des SQL Server ou de l'Oracle, que franchement je ne jetterais pas la première pierre à des MySQLeur amateurs (dont je fais partie d'ailleurs depuis un bail).
Le vrai problème c'est que DBA c'est un vrai métier, et qu'il en faudrait mille fois plus qu'actuellement sur le marché du travail.

**Lyche** · 10/12/2009, 14h55

Mais si les hébergeurs proposent MySQL, c'est aussi parce que, par défaut, c'est un sgbd qui s'est propagés, par l'enseignement du php et donc de MySQL durant les études il y a quelques années (j'ai passé mon BTS il y a 5ans, et c'est sur ça que j'ai été formé). Parce que c'est un sgbd Gratuit, et que 9 fois sur 10 on préfère ne pas dépenser d'argent, quid de la sécurité des données. Il n'est même pas relationnel ce système

**GanYoshi** · 10/12/2009, 14h58

Envoyé par Lyche

Il n'est même pas relationnel ce système

Je te laisse éditer la page wikipedia :

http://fr.wikipedia.org/wiki/MySQL#C...C3.A9ristiques

**Lyche** · 10/12/2009, 15h01

Envoyé par Herve-Loiret

Je te laisse éditer la page wikipedia :

http://fr.wikipedia.org/wiki/MySQL#C...C3.A9ristiques

Si wikipédia le dit

**GanYoshi** · 10/12/2009, 15h02

Envoyé par Lyche

Si wikipédia le dit

Si c'est faux édite le, apporte ta formidable contribution en ouvrant les yeux à ceux qui lisent wikipedia et ceux qui ont écrit cet article

.

Je suis sérieux

**chemanel** · 10/12/2009, 15h05

FAQ Dev.COM :

Est-ce que MySQL supporte les clés étrangères (intégrité référentielle) ?

"Cela dépend du moteur de stockage ; ainsi, InnoDB prend en charge les contraintes d'intégrité référentielle tandis que MyISAM ne le fait pas."

EDIT :

MyISAM : moteur par défaut de MySQL. Il est le plus simple à utiliser et à mettre en œuvre. Il utilise plusieurs fichiers qui grandissent au fur et à mesure que la base grossit. Il ne supporte pas les transactions, ni les clefs étrangères.
InnoDB : moteur créé et maintenu par InnoBase (racheté par Oracle le 7 octobre 2005). Il gère les transactions et les clefs étrangères (et donc une gestion d'intégrité de table). En contrepartie, les bases qui l'utilisent occupent bien plus d'espace sur le disque.

**berceker united** · 10/12/2009, 15h07

Pendant que nous y sommes je vais même rajouter un article que j'ai fais ici même traitant en partie du sujet.

En faisant cette article j'ai découvert les autres possibilité de Mysql et sincèrement je peux difficilement dire que Mysql c'est un truc fait pour les utilisateurs de fer à souder.

http://sony-noel.developpez.com/tuto...mysql/moteurs/

**MadCat34** · 10/12/2009, 15h12

Envoyé par Lyche

Mais cette communauté est forte parce que MySQL est enseigné durant les études de beaucoup de développeurs. Pour notre plus grand malheur. De plus elle est, 3/4 du temps utilisé par des personnes autoformées ou mal formés qui ne s'en servent pas dans les bonnes conditions, ni pour les bonnes appli.

Quelles seraient pour toi de bonnes conditions et les bonnes applications ?
Ca serait intéressant d'avoir un avis plus poussé...

Mais MySQL propose quand même le nécessaire pour une bonne utilisation (View, Triggers, Transaction, Procédures Stockées)...La faiblesse vient surtout de l'utilisateur qui met une base MySQL en place. MySQL permet quand même de gérer des tables de plusieurs millions d'enregistrements sans problèmes (en ayant respecter des le départ les règles de modélisation et avec les bonnes optimisations) et obtenir de bonnes performances.

**Lyche** · 10/12/2009, 15h12

Envoyé par Herve-Loiret

Si c'est faux édite le, apporte ta formidable contribution en ouvrant les yeux à ceux qui lisent wikipedia et ceux qui ont écrit cet article

.

Que ce soit vrai ou faux c'est pas le problème, depuis pas mal de temps je vois des références sur Wikipédia qui débarquent pour clore un sujet alors même que wikipédia est loin d'être sans failles. Que j'ai raison ou tors (je peux me tromper, ça a du évoluer depuis qui j'ai travaillé sur MySQL), ce n'est pas le problème, défendre quelque chose parce que vous vous en servez, refuser d'admettre qu'un logiciel n'est pas viable parce que "la communauté s'en sert" je trouve ça inadmissible et ça jette un discrédit total sur le métier. MySQL n'est pas un bon sgbd et ce quoi qu'on en dise, il n'y pas de comparaison a faire avec SQL Server, pas de "oui mais c'est pour les petits sites" ou de "ça suffi pour ce que j'en fait". Non, utilisez FireBird ou d'autres solution. C'est pas parce que les hébergeurs le proposent par défaut, parce que ça leur coute moins cher, qu'il faut qu'on se laisse faire par 3 bureaucrates qui ne connaissent rien au métier. Maintenant, si vous préférez la facilité au bon fonctionnement, à la sécurité des données et à la performance, libre à vous. Mais ne venez pas me dire que MySQL est un bon SGBD.

**Erwy** · 10/12/2009, 15h18

Petit apparté sur wikipedia.

Je ne lis plus que la version anglaise.
1) la version française est bien moins fournie
2) elle est carrément une calamité sur certains sujet.

J'avais déjà remarqué qu'il y avait des "bizarreries" sur la version française et j'ai déjà un peu contribué sur quelques articles techniques.
Mais je suis récemment tombé sur un blog qui montrait, preuves à l'appuis, les désastres de fr.wikipedia.
Il semblerait que la politique actuelle de l'equipe française c'est de donner la préférence à l'opinion du nombre plutot qu'à celle des experts.
En gros plus un article plait, meilleur il est.

Puisqu'on parle des pratiques de la majorité sur mysql et php, je pense qu'il est facile de voir ou le bât blesse

Les personnes qui se plaignaient étaient d'anciens contributeurs qui n'agissaient plus que sur la version anglaise.Il montraient en exemple des articles ou le sujet était pointus et sans aucun doute sujet à controverse mais ou en voyait des sujets ou on n'avait l'impression qu'un collégien les avaient écrit (et pas un collégien doué...) remplacé d'autre bien rédigés et documentés , plutot type universitaire.
Faudrait que je retouve ce blog

**manudwarf** · 10/12/2009, 15h21

Envoyé par Lyche

Que ce soit vrai ou faux c'est pas le problème, depuis pas mal de temps je vois des références sur Wikipédia qui débarquent pour clore un sujet alors même que wikipédia est loin d'être sans failles. Que j'ai raison ou tors (je peux me tromper, ça a du évoluer depuis qui j'ai travaillé sur MySQL), ce n'est pas le problème, défendre quelque chose parce que vous vous en servez, refuser d'admettre qu'un logiciel n'est pas viable parce que "la communauté s'en sert" je trouve ça inadmissible et ça jette un discrédit total sur le métier. MySQL n'est pas un bon sgbd et ce quoi qu'on en dise, il n'y pas de comparaison a faire avec SQL Server, pas de "oui mais c'est pour les petits sites" ou de "ça suffi pour ce que j'en fait". Non, utilisez FireBird ou d'autres solution. C'est pas parce que les hébergeurs le proposent par défaut, parce que ça leur coute moins cher, qu'il faut qu'on se laisse faire par 3 bureaucrates qui ne connaissent rien au métier. Maintenant, si vous préférez la facilité au bon fonctionnement, à la sécurité des données et à la performance, libre à vous. Mais ne venez pas me dire que MySQL est un bon SGBD.

Mais en quoi est-il si mauvais ? Pour avoir bossé pas mal sur Firebird, c'est bien, mais le support est VRAIMENT bof.

Et puis je te rappelle que si les hébergeurs déploient quasi-exclusivement MySQL c'est SURTOUT parce que c'est hyper léger, en particulier sur les offres mutualisées !

Enfin, stp, montre-nous qu'il n'est pas relationnel, et quelles sont les failles TCP qui s'attaquent à MySQL mais pas à Firebird.

**berceker united** · 10/12/2009, 15h26

Envoyé par Lyche

Que ce soit vrai ou faux c'est pas le problème, depuis pas mal de temps je vois des références sur Wikipédia qui débarquent pour clore un sujet alors même que wikipédia est loin d'être sans failles. Que j'ai raison ou tors (je peux me tromper, ça a du évoluer depuis qui j'ai travaillé sur MySQL), ce n'est pas le problème, défendre quelque chose parce que vous vous en servez, refuser d'admettre qu'un logiciel n'est pas viable parce que "la communauté s'en sert" je trouve ça inadmissible et ça jette un discrédit total sur le métier. MySQL n'est pas un bon sgbd et ce quoi qu'on en dise, il n'y pas de comparaison a faire avec SQL Server, pas de "oui mais c'est pour les petits sites" ou de "ça suffi pour ce que j'en fait". Non, utilisez FireBird ou d'autres solution. C'est pas parce que les hébergeurs le proposent par défaut, parce que ça leur coute moins cher, qu'il faut qu'on se laisse faire par 3 bureaucrates qui ne connaissent rien au métier. Maintenant, si vous préférez la facilité au bon fonctionnement, à la sécurité des données et à la performance, libre à vous. Mais ne venez pas me dire que MySQL est un bon SGBD.

Personne n'a dit que Mysql était un bon SGBD à comparer à SQLServer mais cela ne veut pas dire qu'il est mauvais.

**chemanel** · 10/12/2009, 15h28

Envoyé par manudwarf

... montre-nous qu'il n'est pas relationnel, ...

Envoyé par chemanel

FAQ Dev.COM :

Est-ce que MySQL supporte les clés étrangères (intégrité référentielle) ?

"Cela dépend du moteur de stockage ; ainsi, InnoDB prend en charge les contraintes d'intégrité référentielle tandis que MyISAM ne le fait pas."

EDIT :

MyISAM : moteur par défaut de MySQL. Il est le plus simple à utiliser et à mettre en œuvre. Il utilise plusieurs fichiers qui grandissent au fur et à mesure que la base grossit. Il ne supporte pas les transactions, ni les clefs étrangères.
InnoDB : moteur créé et maintenu par InnoBase (racheté par Oracle le 7 octobre 2005). Il gère les transactions et les clefs étrangères (et donc une gestion d'intégrité de table). En contrepartie, les bases qui l'utilisent occupent bien plus d'espace sur le disque.

**Fallen_Leaf** · 10/12/2009, 15h34

Envoyé par Lyche

Que ce soit vrai ou faux c'est pas le problème, depuis pas mal de temps je vois des références sur Wikipédia qui débarquent pour clore un sujet alors même que wikipédia est loin d'être sans failles. Que j'ai raison ou tors (je peux me tromper, ça a du évoluer depuis qui j'ai travaillé sur MySQL), ce n'est pas le problème, défendre quelque chose parce que vous vous en servez, refuser d'admettre qu'un logiciel n'est pas viable parce que "la communauté s'en sert" je trouve ça inadmissible et ça jette un discrédit total sur le métier. MySQL n'est pas un bon sgbd et ce quoi qu'on en dise, il n'y pas de comparaison a faire avec SQL Server, pas de "oui mais c'est pour les petits sites" ou de "ça suffi pour ce que j'en fait". Non, utilisez FireBird ou d'autres solution. C'est pas parce que les hébergeurs le proposent par défaut, parce que ça leur coute moins cher, qu'il faut qu'on se laisse faire par 3 bureaucrates qui ne connaissent rien au métier. Maintenant, si vous préférez la facilité au bon fonctionnement, à la sécurité des données et à la performance, libre à vous. Mais ne venez pas me dire que MySQL est un bon SGBD.

Et pourtant, c'est un bon SGBD, dans un contexte donné, pour certains types de projets et lorsqu'il est correctement utilisé.
Personnellement, je ne prendrais pas le départ du Paris-Dakar avec une Smart. Tout comme je n'achèterais pas un prototype rallye pour faire des déplacements urbains. (et de toute façon dans les deux cas, si je n'ai pas de notions de conduite, je me crasherais à 99%).

**manudwarf** · 10/12/2009, 15h35

C'est bien parce que tu l'as précisé que je lui demande de montrer le contraire

**Lyche** · 10/12/2009, 15h37

Envoyé par manudwarf

Mais en quoi est-il si mauvais ? Pour avoir bossé pas mal sur Firebird, c'est bien, mais le support est VRAIMENT bof.

Et puis je te rappelle que si les hébergeurs déploient quasi-exclusivement MySQL c'est SURTOUT parce que c'est hyper léger, en particulier sur les offres mutualisées !

Enfin, stp, montre-nous qu'il n'est pas relationnel, et quelles sont les failles TCP qui s'attaquent à MySQL mais pas à Firebird.

Pour le côté relationnel, je pense que ça a évolué depuis. Pour le côté Failles de sécurité, si ça touche MySQL ça touche FireBird hein

. Par contre, le côté gestion de données lâche totalement l'affaire dès que tu dépasses les 200Mo sur une table, et 200Mo c'est pas grand chose en terme de gestion de données.

Les temps de réponses sont doublé, triplés voir plus. Et ce n'est pas une question d'indexation des tables. Que ce soit léger, c'est un plus, mais ça n'empêche pas que le moteur de restitution et de requétage SQL perde en perf très vite, j'ai pas les chiffres en tête.
Qu'ils aient mis en place les systèmes de procédures stockée c'est génial, mais ça vient 5ans trop tard.
Pour le côté support, je t'accorde, avec le plus grand dépit, que côté FireBird, ils sont à la ramasse complet.
Le coté Itératif, MySQL est une base de données Itérative, ce qui empêche les mises à jour en bloc de données. (On ne peux même pas faire une sous requête dans uen bloc Update sour MySQL) Tu veux faire un update de toutes les lignes de ta table, pan tu fais une boucle.

Comment perdre du temps.. ( à moins que ça ai changé avec la dernière version).
Juste un petit exemple. J'ai repris une base de données qui faisait quelques petits traitements en SQL. faire 3 multiplications par ça, arranger les données via lien entre 2 tables, rien de bien sorcier. Il fallait 3 étapes de 1h30 pour faire ça. Pour 2 raisons, la première, c'est que l'appli et la bdd étaient très mal développées. La 2ème, c'est qu'il y avait une table de plus de 300Mo qui faisait que les traitement partaient complètement au large et mettaient un temps fou à se faire.

Ensuite, je te conseil de regarder de ce côté

http://sqlpro.developpez.com/cours/sqlaz/
Bien des fonctions de MySQL Sont hors normes SQL, beaucoup trop. Et c'est une mauvaise chose pour au moins 2 raisons.
1 - Quelqu'un qui va travailler sous MySQL va forcément prendre de mauvais plis et de mauvaises habitudes inhérentes au fonctionnement de MySQL.
2 - Un langage précis utilisé de façon imprécise et non respectueuse de la norme peut entraîner toutes les dérives possibles dans le bidouillage.

Le bidouillage, c'est mal !!

**manudwarf** · 10/12/2009, 15h38

Envoyé par Fallen_Leaf

Et pourtant, c'est un bon SGBD, dans un contexte donné, pour certains types de projets et lorsqu'il est correctement utilisé.
Personnellement, je ne prendrais pas le départ du Paris-Dakar avec une Smart. Tout comme je n'achèterais pas un prototype rallye pour faire des déplacements urbains. (et de toute façon dans les deux cas, si je n'ai pas de notions de conduite, je me crasherais à 99%).

Pourquoi ça revient toujours aux bagnoles ? (même si ta comparaison est bonne)