Base de données · usage courant
Agence MySQL à Nice
La base de données la plus répandue sur les sites et les applications PHP — donc celle que nous rencontrons le plus souvent sur l'existant.
Ce que nous en faisons
MySQL chez nos clients, concrètement
C'est surtout une compétence de reprise : la plupart des sites et des applications PHP qu'on nous confie tournent dessus. Nous les maintenons, nous remettons leurs sauvegardes d'aplomb, et nous migrons quand la migration se justifie — plutôt que de tout réécrire pour changer de moteur.
Les limites
Quand nous recommandons autre chose
Sur un projet neuf, nous partons de PostgreSQL : les mêmes besoins y sont couverts, avec des garanties plus strictes sur les données.
Réalisations
Nos projets menés avec MySQL
Paradigm
Plateforme d'un centre d'affaires niçois : domiciliation, courrier numérisé, messagerie et assistant.
MySQL : Base de données de la plateforme (MariaDB).
Lire l'étude de cas ParadigmHelioneo
Plateforme d'autoconsommation collective : accords, clés de répartition, données Enedis et facturation.
MySQL : Base des producteurs, consommateurs, relevés et factures (MariaDB).
Lire l'étude de cas Helioneo
Méthode
Comment nous intégrons MySQL
Sur une application reprise, la première étape consiste à faire entrer la base dans le projet : nous exportons son schéma, le versionnons dans le dépôt et écrivons chaque modification suivante sous forme de migration numérotée, appliquée dans le même ordre en développement, en recette et en production. Nous créons ensuite des comptes MySQL distincts selon l'usage : un pour l'application, limité aux opérations dont elle a besoin, un pour les sauvegardes, un pour l'administration. Le compte unique doté de tous les droits, fréquent sur l'existant, disparaît.
Les développeurs travaillent sur une copie de la base dont les données personnelles ont été remplacées, montée dans un conteneur à la même version que le serveur. Les tests automatiques s'exécutent contre ce moteur réel plutôt que contre une base simulée, car les écarts entre versions de MySQL, notamment sur les jeux de caractères et le mode SQL strict, n'apparaissent qu'ainsi.
En production, nous activons le journal binaire, qui permet de restaurer la base à un instant précis entre deux sauvegardes complètes. La transmission comprend un document d'exploitation : emplacement des sauvegardes, commande de restauration, liste des comptes et rôle de chacun.
Pour votre entreprise
Ce que ça change concrètement
Pour une PME dont le site ou l'application tourne déjà sur MySQL, l'intérêt principal est de ne pas repartir de zéro. Vos écrans, vos habitudes et vos données restent en place, et le travail porte sur ce qui vous expose : un serveur que personne ne sait reconstruire, des modifications de structure faites à la main sans trace, un accès partagé par tout le monde. Après une erreur de saisie massive ou une suppression accidentelle, la base peut revenir à son état juste avant l'incident, et non à celui de la veille.
MySQL a aussi un avantage pratique : presque tous les hébergeurs le proposent et la plupart des développeurs PHP le connaissent. Un nouveau prestataire trouve dans votre dépôt l'historique des changements de structure et la marche à suivre pour remonter la base, ce qui réduit la période pendant laquelle personne ne maîtrise vraiment l'application. Si votre hébergement ou votre logiciel vous impose MySQL, vous gardez donc une base saine et transmissible sans engager de refonte.
Notre lecture
Ce que nous retenons de MySQL
MySQL n’est presque jamais un choix de conception chez nous, c’est un choix de contexte : c’est la base disponible sur tout hébergement mutualisé, celle que votre prestataire actuel connaît déjà, et celle qui se trouve sous la majorité des sites existants. Sur un besoin transactionnel classique, elle fait le travail sans histoire.
C’est donc la base que nous rencontrons le plus souvent en reprise, aux côtés d’une application PHP. Nos réserves apparaissent sur les requêtes analytiques compliquées et sur la rigueur des types, deux points où PostgreSQL est nettement plus solide ; nous le signalons quand le projet s’y prête et que l’hébergement peut suivre. À l’inverse, pour des documents sans forme stable, ni l’une ni l’autre ne convient et MongoDB est plus honnête.
Grille de décision
Faut-il choisir MySQL ?
Garder MySQL ou passer à PostgreSQL pour notre application existante ?
Garder MySQL, sauf raison précise. Une application PHP qui tourne sur MySQL depuis des années a son code, ses requêtes et ses outils d'administration calés sur ce moteur. Changer de base oblige à retester chaque requête et souvent à réécrire une partie de l'accès aux données, pour un bénéfice invisible pour l'utilisateur. Nous migrons quand un besoin concret l'exige : contraintes d'intégrité mal tenues dans votre cas, fonction absente du moteur, ou refonte déjà engagée.
MySQL ou PostgreSQL pour un nouveau projet ?
PostgreSQL. Sur un projet neuf, rien ne vous attache à MySQL, et PostgreSQL couvre les mêmes besoins avec des garanties plus strictes : typage plus rigoureux, contraintes plus riches, meilleure prise en charge du JSON et des requêtes complexes. L'argument de MySQL reste la compatibilité, avec un hébergement mutualisé ou un logiciel PHP qui l'impose, comme certains CMS. Si c'est votre situation, MySQL convient très bien ; sinon, nous partons de PostgreSQL.
Notre site sur MySQL ralentit : changer de moteur ou optimiser ?
Optimiser d'abord, presque toujours. Les lenteurs d'une base MySQL viennent en général d'index manquants, de requêtes exécutées en boucle par le code PHP, de tables jamais purgées ou d'une configuration serveur restée par défaut. Ces causes se retrouvent à l'identique après une migration vers un autre moteur. Nous analysons le journal des requêtes lentes, corrigeons index et requêtes coûteuses, puis mesurons à nouveau. Un changement de moteur ne se discute qu'après ce travail.
Questions de clients
Ce qu'on nous demande sur MySQL
Notre prestataire a disparu : pouvez-vous reprendre notre site PHP sur MySQL ?
C'est la situation dans laquelle nous rencontrons le plus souvent MySQL. Nous récupérons d'abord les accès à l'hébergement et à la base, puis nous faisons une copie complète avant toute intervention. Nous vérifions ensuite l'état des sauvegardes et les versions de MySQL et de PHP, souvent anciennes. Vous obtenez un état des lieux clair : ce qui fonctionne, ce qui présente un risque et ce qu'il faut corriger en priorité.
Comment savoir si nos sauvegardes MySQL sont fiables ?
Tant qu'une restauration n'a pas été testée, vous ne le savez pas. Nous trouvons régulièrement des sauvegardes arrêtées sans alerte, stockées sur le même serveur que la base, ou incomplètes. Nous mettons en place des sauvegardes automatiques copiées hors du serveur, avec une durée de conservation définie, et nous vérifions périodiquement qu'une restauration aboutit sur un environnement de test. C'est ce contrôle qui fait d'un fichier de sauvegarde une garantie.
Une ancienne version de MySQL pose-t-elle un problème de sécurité ?
Oui, dès qu'elle ne reçoit plus de correctifs. Les failles découvertes ensuite restent ouvertes, et une base joignable depuis Internet devient une cible. La mise à jour n'est pas anodine : certaines requêtes changent de comportement d'une version à l'autre. Nous testons l'application sur la nouvelle version dans un environnement séparé avant de basculer la production, et nous fermons l'accès réseau direct à la base s'il existe encore.
MariaDB et MySQL, est-ce la même chose ?
Presque, mais plus tout à fait. MariaDB est issu de MySQL et reste compatible pour l'essentiel, si bien que de nombreux hébergeurs l'installent à sa place sans le signaler clairement. Les deux moteurs ont toutefois divergé sur certaines fonctions et certains types de données. Avant une mise à jour ou un changement de serveur, nous vérifions lequel vous utilisez réellement et testons l'application sur le moteur de destination, pour éviter une surprise en production.
Peut-on quitter un hébergement mutualisé pour un serveur dédié sans perdre de données ?
Oui, à condition de préparer la bascule. Nous installons MySQL sur le nouveau serveur, importons une copie de la base et vérifions l'application dessus pendant que l'ancien site continue de tourner. Le jour du changement, nous suspendons brièvement les modifications, transférons les dernières données, puis redirigeons le site. L'ancien hébergement reste disponible quelque temps en secours. Le nouvel hébergement est créé à vos identifiants, pas aux nôtres.
Aller plus loin
MySQL s'inscrit dans notre Développement logiciel
Une technologie ne fait pas un projet. C'est la méthode autour qui décide du résultat : cadrage, maquettes, cycles courts, et réversibilité.
Technologies voisines
Un projet MySQL en tête ?
Le premier échange est gratuit. Nous vous dirons franchement si cette technologie est la bonne, et sinon laquelle.
Mis à jour le