Table des matières de l'article :
L'un des aspects les plus frustrants d'être un ingénieur système est de devoir se salir les mains dans des tâches que d'autres professionnels devraient faire.
En effet, il peut arriver qu'après avoir livré un serveur bien dimensionné sur le matériel et bien configuré au niveau logiciel que le client se plaint de performances absolument insuffisantes de l'application qui s'exécute dessus.
Qu'il s'agisse d'un CMS personnalisé, d'un CRM personnalisé ou de toute autre application Web commandée et développée sur mesure selon les besoins du client, l'essentiel est que le logiciel ne fonctionne pas comme il le devrait.
Souvent après les plaintes initiales et calmes, alors que la situation s'aggrave et continue, nous pouvons nous exclamer avec un ton agacé que "Rien ne fonctionneSouvent avec des épithètes, un ton et une terminologie de bar du port.
Après une réponse normale et calme dans laquelle il est souligné à quel point cette configuration est plus que suffisante pour les besoins du client, nous arrivons à l'invitation du client à discuter avec le développeur du logiciel car quelque chose a peut-être dérapé et étant une application personnalisée sans et des cas documentés (comme le logiciel n'est ni connu ni répandu), il pourrait présenter des problèmes critiques évidemment inconnus de nous et non attribuables.
Evidemment pour le programmeur, dans 99% des cas de ce type, le problème n'est jamais dans son logiciel, mais toujours imputable à l'administrateur système qui ne sait pas configurer un serveur.
Et la voici, la plus redoutée des batailles : ingénieur système contre développeur.
L'ingénieur système est généralement une ceinture noire XNUMXe dan d'UNIX, a très probablement une formation en tant que développeur et DBA. C'est le potentiel Bruce Lee capable de vous renverser d'un coup qui préfère TOUJOURS éluder le défi, faute de temps mais surtout de compétences.
Et il est clair, que par compétences, on n'entend pas les compétences théoriques et pratiques ou académiques pour pouvoir analyser brillamment le problème et par conséquent le résoudre, mais ce n'est tout simplement pas de sa compétence, ou que cette tâche a été confiée à une autre personnalité estimée d'une autre entreprise qui est grassement payé pour concevoir et développer des logiciels fonctionnels et bien optimisés.
Dommage que dans la triste vie de l'informaticien et surtout de l'ingénieur système, le jeu du blâme soit toujours au coin de la rue et donc si vous n'acceptez pas le défi à mort, vous serez toujours étiqueté comme celui qui ne le fait pas. savoir comment faire son travail, de même que vous perdrez le client qui ira à une autre entreprise de fumeurs jusqu'à ce qu'un ingénieur système ceinture noire décide de se salir les mains et de prouver une fois pour toutes que tous les problèmes sont venus d'un mauvais mise en œuvre du logiciel.
Non seulement vous aurez sauvé la vie de votre client qui se serait retrouvé avec un logiciel inutilisable, mais aussi du programmeur qui, grâce à vos conseils et vos interventions, aura bénéficié d'une amélioration de son logiciel qu'il pourra même revendre à d'autres les clients.
La vérité ? Vous ne savez pas utiliser MySQL et encore moins SQL en général.
L'un des aspects communs rencontrés par de nombreux développeurs LAMP (Linux Apache MySQL PHP) est celui de ne sachant pas utiliser MySQL. Bien qu'étant arrivé à la version 8, avec un ensemble de fonctionnalités et de fonctionnalités désormais presque enviées par SQL Server de Microsoft, PostgreSQL ou Oracle, la plupart des développeurs continuent de l'utiliser de la même manière qu'avant la version 3.23, c'est-à-dire sans contraintes d'intégrité référentielle, sans procédures stockées, fonctions stockées, déclencheurs, vues ou transactions.
En fait, il faut rappeler aux programmeurs ignorants que même si vous êtes resté à l'âge de pierre en utilisant MySQL de la même manière que 3.23 actuellement le moteur MyISAM de l'époque qui était absolument inadapté à un usage professionnel et moderne a été remplacé par InnoDB et les forks associés dont nous mentionnons surtout XtraDB de Percona Server qui font de MySQL un SGBD relationnel extrêmement puissant.
Personnellement, nous n'avons rien contre MySQL ou MariaDB, mais actuellement, nous avons standardisé pratiquement tous nos serveurs avec Percona Server qui dispose également d'outils accessoires tels que Percona Utilities ou Percona Xtrabackup pour effectuer des sauvegardes à chaud de manière beaucoup plus rapide, plus sûre, plus cohérente et plus efficace que mysqldump banal habituel.
Pour donner un petit exemple, un programmeur aujourd'hui est convaincu qu'un DMBS comme MySQL est un simple tiroir dans lequel stocker et récupérer des données. En d'autres termes, ils utilisent un SGBD très puissant (et donc lourd) comme s'il s'agissait presque d'une base de données NO-SQL et donc légère.
Un SGBD comme MySQL aujourd'hui est plutôt comparable à une ligne de production industrielle avancée qu'à une commode très banale. Bref, ces grandes chaînes de production de bonbons, où sont mis 3 ingrédients principaux et un colorant, au bout du carrousel sortent des paquets d'oursons en gélatine, coupés, mélangés, emballés et prêts à être chargés sur les camions de livraison.
Par exemple, peu de développeurs LAMP savent que MySQL est très puissant et permet de gérer la plupart des opérations qui se font au niveau de l'application, directement au niveau de la base de données puisque MySQL lui-même possède un langage de programmation interne.
Voyons quelques-unes des principales lacunes ou mauvaises pratiques de ceux qui développent des applications Web à l'aide de MySQL.
La lecture suivante peut transformer n'importe quel ancien développeur Web recyclé peracottaio au chômage en un bon développeur et peut-être même un bon DBA si vous continuez sur cette voie.
1. Clés étrangères et intégrité référentielle
Le programmeur est convaincu que seul PHP existe, que si vous souhaitez supprimer les enfants d'un nœud, vous ne pouvez le supprimer que via le côté application, en interrogeant d'abord les résultats à supprimer, puis en les supprimant un par un puis en revenant ensuite à la table parent et en supprimant l'élément. De la même manière ils sont convaincus que si vous voulez utiliser une formule mathématique pour un calcul complexe cela ne peut être effectué que par PHP qui produira un résultat qui sera ensuite écrit dans la BD.
Ils ne savent pas, par exemple, que pour supprimer un artiste et tous ses albums d'une hypothétique base de données d'archives musicales vous pouvez utiliser l'action ON CASCADE DELETE qui permet d'effectuer une annulation référencée à l'annulation de la clé étrangère correspondante sans aller pour supprimer individuellement les valeurs individuelles.
Dans le contexte du SGBDR, l'intégrité référentielle est une contrainte d'intégrité inter-relationnelle qui est une propriété de données qui, si elle est satisfaite, requiert que chaque valeur d'un attribut (colonne) d'une relation (table) existe en tant que valeur d'un autre attribut dans une autre relation.
De manière moins formelle, dans les bases de données relationnelles, pour que l'intégrité référentielle soit respectée, chaque champ d'une table qui a été déclaré comme clé étrangère ne peut contenir que des valeurs de la clé primaire ou de la clé candidate d'une table "parente" liée.
Par exemple, la suppression d'un enregistrement contenant une valeur référencée par une clé étrangère d'une autre table violerait l'intégrité relationnelle. Certains SGBDR peuvent garantir l'intégrité relationnelle, soit en supprimant les lignes respectives de la clé étrangère, soit en interrompant l'opération et en n'effectuant pas la suppression.
2. Procédure stockée
Les procédures stockées sont une autre fonctionnalité dont l'absence a longtemps été soulignée par les détracteurs de MySQL : avec la version 5.0, cette absence a enfin été comblée.
Une procédure stockée est un ensemble d'instructions SQL stockées sur le serveur avec un nom qui les identifie ; ce nom permet de ré-exécuter le jeu d'instructions simplement en s'y référant.
Chaque procédure peut avoir un ou plusieurs paramètres, chacun étant constitué d'un nom, d'un type de données et d'une indication indiquant s'il s'agit d'un paramètre d'entrée ou de sortie ou des deux. Si l'indication manque, le paramètre est considéré comme entré.
3. Fonctions stockées
Les fonctions stockées sont similaires aux procédures stockées, mais ont un objectif plus simple, qui est de définir des fonctions réelles, telles que celles déjà fournies par MySQL. Elles renvoient une valeur et ne peuvent donc pas renvoyer d'ensembles de résultats, contrairement aux procédures stockées. Dans les versions de MySQL antérieures à la 5.0, il y avait des "fonctions définies par l'utilisateur", qui étaient stockées à l'extérieur du serveur. Maintenant, ces fonctions sont toujours prises en charge, mais nous vous recommandons vivement d'utiliser les nouvelles fonctions stockées.
4. Déclencheurs
Les déclencheurs sont des objets associés aux tables, qui sont activés lorsqu'un certain événement se produit en relation avec cette table. Ils ont été introduits à partir de MySQL 5.0.2.
Lorsque nous définissons un déclencheur, nous établissons pour quel événement il doit être activé (insertion de lignes, modifications ou suppressions) et s'il doit être exécuté avant ou après cet événement ; nous aurons alors les types de déclencheurs suivants :
AVANT INSÉRER
AVANT LA MISE À JOUR
AVANT DE SUPPRIMER
APRÈS INSERTION
APRÈS LA MISE À JOUR
APRÈS SUPPRIMER
Le déclencheur établira une instruction (ou une série d'instructions) qui sera exécutée pour chaque ligne affectée par l'événement. En d'autres termes, si je veux activer quelque chose lorsqu'un événement défini se succède, le déclencheur n'activera quelque chose que lorsque l'événement défini se produira. Par exemple, si nous voulions mettre à jour le champ du total vendu pour un agent commercial dans le mois en cours, nous pourrions activer un déclencheur qui se déclenche lorsqu'une nouvelle valeur est saisie dans la table des commandes qui fait la somme de toutes les commandes de le mois et écrivez la valeur dans le tableau des totaux du mois. Cela donnerait la possibilité d'avoir toujours une donnée pré-calculée qui est mise à jour à chaque nouvelle commande, plutôt que d'avoir sélectionné que dans le backend de l'agent recalcule la valeur à chaque fois en additionnant toutes les ventes du mois.
5. Vues
Les Vues (terme traduit en italien littéralement par le mot « Vues »), sont des tables temporaires, qui se comportent comme de vraies tables mais qui en réalité ne contiennent pas de données « physiquement » ; comme toute autre table, une vue est composée de lignes et de colonnes mais dans ce cas elles sont le résultat d'une requête qui est stockée comme s'il s'agissait d'un objet.
En créant une vue, tout ce que vous faites est de stocker le sous-ensemble d'une table existante via un processus de requête SGBD, ce sous-ensemble vous permet de faire référence aux propriétés et aux méthodes de l'objet archivé de la même manière que vous pouvez utiliser n'importe quelle autre table.
6. Opérations ACID
L'utilisation des transactions permet de "consolider" les modifications apportées à la base de données uniquement à un moment précis : à partir du moment où nous commençons une transaction, les mises à jour restent suspendues (et invisibles pour les autres utilisateurs) jusqu'à ce que nous les confirmions (commit) ; comme alternative à la confirmation, il est possible de les annuler (rollback). En termes simples, le concept est tout ou rien. Si vous avez 100 enregistrements à saisir peut-être dans une commande de restaurant et qu'au 90, l'entrée est bloquée car le Wifi ne fonctionne pas, alors le système annulera toute la transaction en annulant les 90 entrées car elles ne complètent pas le total des 100 entrées ils auraient dû l'être.
Et n'oublions pas les performances.
Si on voulait parler de vitesse d'exécution des requêtes, on peut dire que de moins en moins de développeurs LAMP savent concevoir correctement une base de données et implémenter une utilisation correcte des index qui sont absolument indispensables si l'on veut accélérer l'exécution des requêtes elles-mêmes.
Autrement dit, très souvent des applications lentes qui arrivent au timeout de connexion et même à la saturation du maximum de connexions disponibles ont pour seule cause le manque d'index sur les tables.
Un index de base de données est une structure de données qui améliore la vitesse des opérations sur une table.
Chaque fois qu'une application Web envoie une requête à une base de données, la base de données recherchera toutes les lignes de votre table pour trouver celle qui correspond à votre demande. Au fur et à mesure que vos tables de base de données grandissent, davantage de lignes doivent être inspectées à chaque fois, ce qui peut ralentir les performances de la base de données et donc de l'application.
Les index MySQL résolvent ce problème en prenant les données d'une colonne de votre table et en les stockant par ordre alphabétique dans un point séparé appelé index.
Juste que ça marche ? Non, ça doit être rapide.
Bref, bref, bref, il semble que le principal problème de ceux qui développent LAMP soit qu'ils se concentrent plus sur la programmation PHP que sur la conception et l'optimisation de bases de données. Sans une formation académique claire, il semble courant que le développeur teste simplement le logiciel localement sur de très petits ensembles de données et peu de concurrence. On peut dire que le logiciel fonctionne et que la requête renvoie les bons résultats, mais c'est une chose de tester le logiciel sur 100 enregistrements de démonstration avec un seul utilisateur connecté, une autre chose est de travailler sur des ensembles de données de dizaines de millions de records avec 100 opérateurs connectés en temps réel.