Absolument d'accord depuis plus de 10 ans !
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.
Le problème de MySQL est plutôt dans certaines optimisations manquantes sur des fonctions avancées
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.
ET POUR LES GROSSES BASES ?
POSTGRES est définitivement plus qu'une alternative à Oracle ou SQLServer, n'en déplaise à certains DBA frileux ou adeptes du clickodrome qui le trouvent "ennuyeux".
Au contraire, et c'est même sans doute là que l'on reconnait les vrais professionnels, hihihi.
Soulignons que la question de la performance comparée ORACLE/PostGresql n'est digne que des commerciaux du premier et un faux débat à une époque où le prix de la licence Oracle équivaut à celui d'une batterie de machines physiques hébergeant une armée de machines virtuelles.
Un DBA (et j'en suis depuis ORACLE V4 en 1985) arrivera toujours à faire marcher un SGBD, surtout s'il sait (faire) paralléliser et utiliser les ressources matérielles contemporaines citées ci-dessus.
Notons que le mode de gestion de la mémoire cache de PostGres partageant le cache de fichiers système impose une machine virtuelle dédiée à chaque instance, ce qui est décidément le sens de l'histoire.
Tout ce qui précède est valide dans un contexte sérieux : bases de plusieurs (dizaines de) To, contenant des tables partitionnées de plusieurs milliards d'enregistrements et avec un taux d'insertion dépassant 1000 enrts/s.
Et c'est précisément là que PostGres n'est pas du tout ennuyeux, et permet de déchainer sa créativité, à la différence d'Oracle où il faut sans cesse aller voir son chef ou son client pour une improbable extension de licence de ceci ou de celà.
Sinon, plus petit, il y a ce que vous préférez à un moment donné, et ce pourra être n'importe quoi : Mysql (qui appartient à Oracle), MariaDB, Access (oui, oui, qui peut s'avérer très amusant), Sqllite...
En revanche, migrer soi-même d'Oracle à PostGresql peut être une galère, mais ça existe, des sociétés spécialisées le font assez bien.
Il faut donc faire virer leur cuti aux développeurs (mais yapa la fonction COUNT(*) ?) et aux DBA (zone de confort, invitation aux grand-messes Oracle annuelles) AVANT la conception du projet.
Terminons en précisant justement que sur un site important, le coût de licence/maintenance d'Oracle peut représenter le salaire de plusieurs ingénieurs.
Alors autant payer des salaires à des jeunes (ou pas) en France qu'enrichir Larry Ellison, non ?
