Discussion :

[abriotde]

Ce qu'il dis, c'est simplement que MySQL optimise mal les requêtes mal fichues. Mais si la requête est simple et bien optimisé, il n'y a pas de problèmes de performances. On utilise MariaDB (eh oui MySQL est délaissé par Oracle) à très forte dose (BDD de plusieurs teraoctets avec des dizaines milliers de tables et parfois des tables de plusieurs 100aines de Giga et de plusieurs milliard d'enregistrement) avec d’excellentes performances quand la requête est bien optimisé.

Mais l'avantage de MySQL est qu'il permet surtout de faire ce que l'on veut simplement. Il économise le prix d'une licence Oracle, d'un DBA et de complexités totalement inutile au seul prix d'une optimisation un peu plus importante en amont.

Dis autrement, la recherche de performances n'est pas toujours intéressante si elle ne permet pas de faire évoluer le système simplement. La solution performante et complexe est parfois moins intéressante (moins robuste et parfois même moins performantes dans certains cas) que la solution simple.

Autre chose, Oracle oblige a avoir un serveur SQL différent du serveur qui traite la donné, et ça c'est une perte de performance (minime mais tout de même) et cela ajoute de la complexité (gestion réseau...) et des causes de pannes (réseau) qui n'est pas toujours utile.

[koyosama]

Les gens ont un peu la memoire courte, a une epoque, la seul base de données pour les debutants c’était MySQL. Apres en tant que professionnel, on peut choisir.
Je pense que celui qui est devenu le plus répandu est celui qui a offert une IHM, meme aujourd'hui postgres, pG admin c'est pas ouf. Et les outils autour de Windows ne sont pas ouf non plus.

Mais quand j'ai commence la programmation, c’était le seul sans prise de tete.

Est-ce que moi a l’époque en tant qu’étudiant ou hobbyiste, avoir des licenses SQL Server ou Oracle c’était pas simple. Je sais que SQL Server existe en version lite, il y a aussi postgres, mais franchement c'est un peu la misère. Apres je suis sur qu'on a tous essayer WAMP, MAMP, XAMP, EasyPHP (pour les plus malchanceux).

Non MySQL devrait être au pantheon pour avoir démocratiser et former les développeurs d'une generation.
C'est pas la meilleure base de données, mais juste pour faire une pauvre base, c'est le truc qu'il fallait. Apres je ne serais pas surpris que MySQL meurt, Oracle c'est quand meme une des entreprises des plus maléfique je connais.
Et puis les debutants ne maîtrisent pas toujours l'installation de la base de données mais le code avant. En plus les hébergeur web le démocratisé plus.

[SQLpro]

Ce qu'il dis, c'est simplement que MySQL optimise mal les requêtes mal fichues. Mais si la requête est simple et bien optimisé, il n'y a pas de problèmes de performances. On utilise MariaDB (eh oui MySQL est délaissé par Oracle) à très forte dose (BDD de plusieurs teraoctets avec des dizaines milliers de tables et parfois des tables de plusieurs 100aines de Giga et de plusieurs milliard d'enregistrement) avec d’excellentes performances quand la requête est bien optimisé.

Je serais curieux d'avoir ces référence de bases de données de plusieurs To. En effet je n'en n'ai jamais vu une seule fonctionner... Malgré de très nombreux audits d'entreprise.... En effet qu dessus de quelques dizine de Go dans une même base, MySQL rend l'âme avec le célèbre message "MySQL ha gone away..."

Mais l'avantage de MySQL est qu'il permet surtout de faire ce que l'on veut simplement. Il économise le prix d'une licence Oracle, d'un DBA et de complexités totalement inutile au seul prix d'une optimisation un peu plus importante en amont.

Dànc, des salaires en plus pour cette optimisation qui généralement coutent plus cher à l'entrprise que le paiement d'une licence... Un informaticien coutant environ 5000€ par mois à l'entreprise en comptant les charges et l'infrastructure (loyers, outils, licences...)

Dis autrement, la recherche de performances n'est pas toujours intéressante si elle ne permet pas de faire évoluer le système simplement. La solution performante et complexe est parfois moins intéressante (moins robuste et parfois même moins performantes dans certains cas) que la solution simple.

Va donc dire a ton patron que les performances ne l’intéresse pas et que donc il doit payer plus cher d'électricité par exemple.... !

Autre chose, Oracle oblige a avoir un serveur SQL différent du serveur qui traite la donné, et ça c'est une perte de performance (minime mais tout de même) et cela ajoute de la complexité (gestion réseau...) et des causes de pannes (réseau) qui n'est pas toujours utile.

Encore une analyse débile sur l'infrastructure. Un SGBDR possède un fonctionnement particulier qui est incompatible avec la plupart des autres applications et même avec une autre instance de lui même du fait de la concurrence d'accès !

Ne pas comprendre le B A BA de ces principe prouve que votre savoir sur ce sujet est d'une vacuité intense !

A +

[Invité]

Historiquement, le principal intérêt de MySQL est d'être installable sur un serveur sans pour autant en monopoliser les ressources. Ajouté à cela, le logiciel est longtemps resté librement distribuable. C'est pour cela que le SGBD a remporté un franc succès dans les applications web.

MS SQL server a une philosophie totalement à l'opposée. Le logiciel fonctionne mieux s'il tourne seul sur un serveur. Et le système de licence n'est pas propice aux déploiements massifs.

[kedare]

MS SQL server a une philosophie totalement à l'opposée. Le logiciel fonctionne mieux s'il tourne seul sur un serveur.

C'est le cas de toutes les bases de données.

SQL Server est très simple a "contenir" dans les ressources qui luis sont allouées, tu peux lui attribuer que certains cores et lui limiter sa mémoire utilisable très simplement.

[vanquish]

Ajouté à cela, le logiciel est longtemps resté librement distribuable.

En réalité, la licence mySQL ne permet pas un déploiement aussi libre que cela.
Bien sur je peux le mettre sur mon serveur en téléchargement gratuit à coté d'autres logiciels libres.
Je peux en installer autant d’instances que je veux en interne dans ma structure.

Mais beaucoup de distributions violent la licence qui a une vue très restrictive du GPL, puisque MySQL considère que si vous distribuez votre application en même temps que MySQL et que votre application nécessite MySQL, alors votre application et MySQL forment un tout dont l'ensemble doit être GPL.

Cela ne date pas d'Oracle. Cela avait déjà posé un problème pour le bundle LAMP puisque le les 4 produits (Linux/Apache/MySQL/Php) n'étaient pas tous sous GPL.
La version community a toujours été un produit d'appel pour la version purement commerciale.

Beaucoup de petits éditeurs considèrent MySQL/MariaDB comme un produit gratuit qu'ils peuvent distribuer gratuitement avec leur application, mais ils ont tord (à moins que leur application soit 100% GPL).

Le rachat d'Oracle a fait passer la licence commerciale de 500€/perpétuel à 5000€/an, mais la philosophie a toujours été la même et s'est inévitablement propagée au fork MariaDB.

Je distribuais très régulièrement des licences commerciales de mySQL. Après le rachat par Oracle, je suis passé à Firebird.
Comme je ne commandais plus de licences, j'ai eu un appel téléphonique étonné d'un commercial d'Oracle qui, plus menaçant que commercial, m'a fermement rappelé les conditions de distribution de mySQL.

Je continue de considérer MariaDB comme plus performant que Firebird (même si l'écart se tasse depuis la V3), mais en terme de liberté de distribution, il n'y a pas photo : Firebird est loin devant.

[blbird]

EJe distribuais très régulièrement des licences commerciales de mySQL. Après le rachat par Oracle, je suis passé à Firebird.
Comme je ne commandais plus de licences, j'ai eu un appel téléphonique étonné d'un commercial d'Oracle qui, plus menaçant que commercial, m'a fermement rappelé les conditions de distribution de mySQL.

Oracle est une véritable plaie en termes de licences, agressifs et absolument pas compréhensifs. A bannir autant que possible de tout S.I.

[walfrat]

Je serais curieux d'avoir ces référence de bases de données de plusieurs To. En effet je n'en n'ai jamais vu une seule fonctionner... Malgré de très nombreux audits d'entreprise.... En effet qu dessus de quelques dizine de Go dans une même base, MySQL rend l'âme avec le célèbre message "MySQL ha gone away..."

Dànc, des salaires en plus pour cette optimisation qui généralement coutent plus cher à l'entrprise que le paiement d'une licence... Un informaticien coutant environ 5000€ par mois à l'entreprise en comptant les charges et l'infrastructure (loyers, outils, licences...)

Va donc dire a ton patron que les performances ne l’intéresse pas et que donc il doit payer plus cher d'électricité par exemple.... !

Encore une analyse débile sur l'infrastructure. Un SGBDR possède un fonctionnement particulier qui est incompatible avec la plupart des autres applications et même avec une autre instance de lui même du fait de la concurrence d'accès !

Ne pas comprendre le B A BA de ces principe prouve que votre savoir sur ce sujet est d'une vacuité intense !

A +

Bien que le ton laisse à désirer, je pense que les downvotes ne sont absolument pas justifié.

Aux dernière nouvelles que j'avais, la "limite physique" de données qu'une instance des meilleurs SGBDR considérée 5To, ceci a cause des contraintes impliquant l'utilisation d'un SGBD relation (ACID).

Edit : N'ayant plus l'affirmation en tête, je vais nuancer, 5To était plutôt une sorte de répère ou une instance unique de SGBDR pour un usage général (en termes de données, concurrences d'accès) commence à montrer ses limites. Evidemment on peut aller plus loin avec des solutions sur mesures ou des cas d'usage spécifiques. (+répartition de données sur plusieurs serveur etc etc).

Je ne peux donc qu'être que peu convaincu quand je vois quelqu'un balancer que MYSQL, mais aussi un autre SGBD peut gère des centaines de milliards d'enregistrements et des centaines de terraoctets en une seule instance est très suspect. Certes, c'est dit d'une façon qu'on est pas sur que tout soit une seule instance de MYSQL ou plusieurs tournant séparément mais franchement sans plus d'infos, ça manque de crédibilité.

Enfin vouloir faire croire que tu peux faire tourner des milliards d’enregistrement correctement sans DBA, quelque soit le SGBD, en supposant que ton SGBD est pas juste une sorte de table de log avec une seule table et 4 colonnes de texte, c'est juste hilarant.

Je m'estime déjà comptant en tant que développeur de ne pas avoir peur de frôler le million d'enregistrement sur les tables les plus chargées d'un schéma de plusieurs dizaine de tables, tant que je peux posé le schéma d'une base de données convenablement, alors faire genre qu'on peut s'improviser de gérer une BDD de la taille de facebook ou Twitter juste avec un dev full stacks, juste... non.

[walfrat]

Votre méconnaissance est importante... Pour information, une des plus grosse base de données du monde est sur MS SQL Server après plusieurs Po (péta octets) c'est a dire plusieurs milliers de To... Et cela ne date pas d'aujourd'hui, mais de plus de 10 ans...
Pann Starrs :
https://fr.wikipedia.org/wiki/Pan-STARRS

Pour votre information également CDsocunt c'est plusieurs dizaine de To depuis près de 10 ans... Comme Fnac.com ou ventes privées devenu Vepee.

Donc, mettez vos connaissance à jour avant d'affirmer de telle idioties !

A +

le problème c'est que je n'ai plus l'affirmation en tête vu que ça fait longtemps, mais je l'ai très mal tourné c'est sur.

Evidemment il ne s'agit pas de 5To qu'on peut juste remplir avec des énormes volumes de données binaires., une image satellite de ce qu'on prend pour la Terre, ça pèse déjà plusieurs gigas à elle seule .

1,4 téraoctet d'images sont produites chaque nuit par Pan-STARRS et les données astronomiques sont stockés dans un système de base de données relationnelle Microsoft SQL Server 2008 sous Windows organisé en cluster à 12 nœuds comprenant 100 To de données

100/12 = 8To/instance. + les images évidemment.

En outre il s'agissait d'une estimation que les SGBDR pouvait gérer en général de 5TO sur une seule instance, en customisant la base pour des besoins spécifiques, et en séparant les données sur des instances séparés, bien sur qu'on peut aller plus loin et que c'est déjà fait, ou aussi en utilisant la base de telle façon qu'il y a extrêment peu de concurrence sur les enregistrement, mises à jour d'index etc.

En 2008, 300 To de données figurait dans la base de Pan-STARRS.

Je précise, j'ai bien vu ça, mais sans trop de précision je ne sais pas si c'est toujours sur 12 noeuds ou si'l y a une contradiction avec ce qui était dit dessus, toujours que 300/12 =>25To, on est pas non plus si loin de ça des 5To que j'avais cité (en termes d'ordre de grandeur).

C'est juste que pour moi, 5To, c'est déjà un bon repère pour savoir quand tu rentres vraiment dans le hard de ce que peuvent faire les SGBD les plus costaud, surtout quand quelqu'un met qu'il peut faire du MysQL sans DBA avec des centaines de terras.

[Mat.M]

Je serais curieux d'avoir ces référence de bases de données de plusieurs To. En effet je n'en n'ai jamais vu une seule fonctionner... Malgré de très nombreux audits d'entreprise....

c'est pour cette raison que les infrastructures comme Azure ou AWS sur le Cloud se développent

Donc le benchmark de notre ami SQLpro est malheureusement sans intérêt, à part si comme notre ami SQLpro on s'est donné comme mission de faire de la propagande SQL Server au détriment des bases de données open source.

votre vision des choses c'était valable il y a quelques années auparavant.
Maintenant elle est devenue obsolète.
Le problème lorsqu'on veut crée un système informatique avec gestion de données c'est pas à savoir s'il faut prendre de l'open-source ou pas
Le problème c'est la montée en charge du système d'information bref la scalabilité du système d'information.
Et même MySQL propose une solution sur le Cloud évidemment payante...

[SQLpro]

... Le problème c'est la montée en charge du système d'information bref la scalabilité du système d'information.
Et même MySQL propose une solution sur le Cloud évidemment payante...

Mais le cloud n'est pas la solution de scalabilité des RDBMS ! Les solutions de montée en charge (volume, concurrence...) des SGBDR sont internes... Exemple avec Oracle RAC ou SQL Server avec AlwaysOn et les Distributed Partitionned Views (DPV).

A +

[spl33n]

Avez-vous expérimenté les SGBD MySQL et PostgreSQL ? Lequel préférez-vous ?

Comme évoqué précédemment, j'ai fait mes premières armes avec MySQL avant de migrer. La question du choix de SGBD est dans la même lignée que dans une distrub linux : tu adhères à l'approche ou non (Ubuntu vs Debian par exemple), la finalité est prise en compte également, l'employeur impose un outils ou non. PostgreSQL s'optimise bien via les *.conf, MySQL autant pas se casser la tête (en même temps j'ai survolé la question.. sqlite3 serait tout aussi bien alors =) )
L'autre jour, je regardais avec Django pour les recherches simples via un formulaire. Bah y'a quand même pas mal de chose (outils) dispo uniquement pour Postgresql (même si la connexion peut devenir casse-pied parfois). A une époque, la connexion entre Joomla/Postgresql était limite une perte de temps (ça a changé ?)

Pensez-vous que MySQL est médiocre ? Quel est votre avis sur la réaction de l'ingénieur Oracle en partance ?
Le principale mérite de MySQL/MariaDB est effectivement sa facilité d'usage avec des interface comme phpmyadmin. L'installation d'un CMS/site basique se fait en même pas une heure. La question est dans la fin : si j'ai des milliers d'entrées à terme et quels types de données, ça n'est plus pertinent. Si on fait du SIG, la question est résolue en même pas 2sec : Postgresql, il a toujours été complémentaire de QGIS/Postgis aussi loin que je m'en rappelle.

« PostgreSQL, malgré son exactitude académique et l'ensemble de ses fonctionnalités, de ses requêtes avancées, est très ennuyeux », partagez-vous cet avis ?
Au cas par cas, c'est pour ça que la comparaison de perf (MS SQL/MySQL/sqlite3/Postgresql/..) n'est pas forcément pertinente en gros, une croisade ou une démonstration de la plus grosse n'a que peu d'intérêt.
Je raisonne simplement :
- soft de contenu : mysql
- soft "à données" et support : ms sql / oracle
- soft à données géo-spatialisées et pas cher : postgresql
- soft de test rapide ou à très faible volume : sqlite3

Et on évite mysql+postgresql.. Autant optimiser le système, pas que le sgbd. L'administration db c'est un métier plein, comme développeur ou administrateur système et réseaux. Les 3 travaillent ensemble.

[moueza]

.C'est vrai que MySQL m'a toujours paru simple d'utilisation, d'installation (apt), léger (au contraire d'oracle qui prenait de Go, en plusieurs fichiers lol).
.Postgresql m 'a toujours été '"vendu" comme hyper stable, plus avancé en objet, avancé en GIS. Moins utilisé par les newbies, sans doute car moins de pub ; et souvent utilisé dans le monde professionnel.

[Christ D]

MySQL : une source d'ennui sans fin :
- utilisée à tort et à travers y compris pour de toutes petites bases de données alors que le serveur est une usine à gaz sans nom.
- une psychose de la sécurité qui rend l'installation de plus en plus longue et difficile (évidement vu que les utilisateurs ont pris pour habitude de connecter leur site à leur base en utilisant le owner de la base, qui a tous les droits dessus, y compris de la dropper !)
- la possibilité de compiler une procédure stockée exécutant une requête dont une colonne ou une table n'existe pas !
- la possibilité de dropper un objet alors qu'il reste utilisé dans le code !!!! (Ex : drop de table alors que des procédures l'utilisent) !
- Ce n'est que depuis peu que MySQL gère les procédures stockées !
- changez de version et votre code ne fonctionne plus ! C'est tellement vrai que beaucoup utilisent encore MySQL 5.6 !!!!
(changement de code SQL dans les procédures stockées, déprécation de charset , changement de syntaxe de LOAD DATE, interdiction de chargement de fichier par défaut !!!!!! etc.....)
- comment est-il possible de faire un SGBDR qui, lorsqu'on créer une clé étrangère, ne génère pas l'indexe en même temps ?
- comment est-il possible que MySQL ne sache toujours pas gérer les clés étrangères a plusieurs colonnes ? Impossible d'exploiter des clés naturelles, on en revient toujours aux auto-incréments.

Et avez vous vu une seul fois WorkBench fonctionner sans bug gênant ?

La durée de restauration d'une base MySQL est aussi déconcertante (4h pour restaurer une base dont le backup fait 300Mo sur un serveur de dev avec disque en SSD avec un intel i7 et 16Go de RAM).
La restauration d'un backup de 300Mo sur Firebird (190 tables, 160 procédures stockées) sur la même machine dure 1 minute ! Certe, le format de backup n'est pas le même.

Dans l'ordre de mes préférences des SGBDR open source, selon les cas :
- petite base de données sans procédures stockées ni gestion des droits ==> sqlite
- une base avec procédures stockées, fonctions internes, gestion des droits, bonnes performances et exigeant relativement peu de connexions simultanées == > Firebird !
- besoin de plus ? ==> PostGresql

MySQL = ni fait, ni à faire.

[vanquish]

MySQL : une source d'ennui sans fin.

Je n'ai pas du tout la même expérience.
Comme je l'ai écrit ailleurs, je suis passé de mySQL à Firebird, mais pas à cause du logiciel.

J'ai toujours des dizaines d'instances et je n'en entend jamais parler.
Les dump sont au dessus du Go et ne mettent pas 4h pour être remonté, loin de de là.

Un dump 1,5 Go sur mon ordi portable SSD, trop vieux pour avoir droit à W11, ça se remonte en 20 min maxi.
Alors 4h pour 300 Mo, je ne pige pas.

De plus, pour InnoDB (le moteur que j'utilise systématiquement) il a toujours existé un backup binaire à chaud (et transactionnel).
Je l'achetais moins de 400€ directement auprès de InnoDB avant le rachat par Oracle.

Percona en a fait une version open-source que MariaDB intégre à sa version community.
(Le binaire Percona n'est dispo que sur Linux, mais le binaire MariaDB est aussi dispo sous Windows)

Avec ce système, remonter une base c'est faire un xcopy.
Difficile de faire plus rapide.
Le seul soucis c'est que cela backup toute l'instance (et pas seulement une base).

J'ai eu bien plus de problème avec Firebird.
Avec les version antérieur à la 3, on pouvait se retrouver avec une base qu'il était possible de sauvegarder, mais dont la sauvegarde ne pouvais être remonté à cause de soucis d'intégrité référentielle ou de valeur de champ date incohérente. Mes recherches sur internet m'ont montré que je n'étais pas tout seul.
Des sauvegardes sur lesquelles on ne peut pas compter, ce n'est pas des sauvegardes.

[SQLpro]

Quelques exemples de manques de MySQL face à SQL Server :

• Pas de cache des plans d'exécution des requêtes
• Pas de parallélisme d'exécution des requêtes
• Aucun autre algorithme de jointure que la boucle imbriquée qui est l'algorithme le plus lent
• Inconsistance de la clause GROUP BY
• Pas de tables In Memory
• Pas d'index verticaux (columstore)
• Pas d'indexation du XML
• Pas de tables de graphe ni le langage (GQL : Graph Query Language) qui va avec
• Pas de "big table" (SQL Server peut monter jusqu'à 30 000 colonnes)
• Pas de compression des données des tables et index
• Pas de table de type paire clé / valeur comme Redis
• Pas de datalink (norme SQL) comme le FILESTREAM de SQL Server

...

[walfrat]

Je suis pas le seul à ne pas être à jour : https://dev.mysql.com/doc/refman/8.0/en/hash-joins.html (MySQL 8.0.20 (2020-04-27, General Availability) )

En outre que MySQL ne peut pas gérer des tables à 30k colonnes, sérieusement on s'en fou.

C'est pas la faute de MySQL si des gens veulent l'utiliser pour gérer des centaines de millions de données alors qu'il n'a jamais été développé dans cet esprit ni n'a jamais eu les moyens de le faire comme SQL Server.

Tu casses juste du sucre gratuitement sur MySQL plutôt que sur les personnes qui le choisissent, c'est pas vraiment pro tout ça.

[SQLpro]

Je suis pas le seul à ne pas être à jour : https://dev.mysql.com/doc/refman/8.0/en/hash-joins.html (MySQL 8.0.20 (2020-04-27, General Availability) )...

Extrait de la doc Oracle :
Beginning with MySQL 8.0.18, MySQL employs a hash join for any query for which each join has an equi-join condition, and in which there are no indexes that can be applied to any join conditions, such as this one:
Ce qui limite considérablement la chose....

Comme si on disait, vous pouvez prendre des pneu neige, uniquement s'il neige et fait entre 0 et -3 degré avec un vent latéral de moins de 30 km/h.... !

A +

[01001111]

Comme il a été dit dans certains des commentaires, MySQL est plutôt performant sur des requêtes simples...
Un des problèmes qui peuvent survenir, c'est par exemple, sur des tables avec de relativement nombreuses entrées, d'utiliser les vues avec des définitions d'algorithmes en interne.
J'ai récemment optimisé une vue qui se construisait sur un table de "seulement" 33k entrées, et qui mettait 42 secondes à se construire (je n'ai pas programmé cette horreur), en remplaçant cette vue par une table réelle construite à partir d'un script php/mysql qui a mis moins d'une seconde à s'exécuter la première fois et se met à jour toutes les heures en moins de 50ms, j'obtiens le même résultat que la vue...

Le tout est donc d'utiliser MySQL dans ce qu'il sait faire au mieux, à savoir des choses simples. Lui adjoindre un second langage pour les choses complexes est chose requise.

[Pierre Fauconnier]

[...]
Le tout est donc d'utiliser MySQL dans ce qu'il sait faire au mieux, à savoir des choses simples. Lui adjoindre un second langage pour les choses complexes est chose requise.

Comme toujours, utiliser le bon outil en fonction du besoin et des compétences techniques de qui met l'outil en place.