Les bases de données

1. Le choix du système de gestion de base de données

Le choix d’un système de gestion de base de données (SGBD) est généralement dicté par des considérations plus économiques et techniques (nombre d’accès…) qu’écologiques. Le choix de l’hébergeur et de sa formule impose bien souvent le SGBD. La plupart des offres proposent le système de gestion de base de données MySQL ou son fork communautaire MariaDB. C’est pourquoi cet ouvrage se concentre sur ces SGBD. Néanmoins, son contenu est pour l’essentiel transposable aux autres SGBD.

2. Le choix du moteur de stockage

MySQL a plusieurs moteurs de stockage, mais deux sortent du lot : MyISAM et InnoDB. MyISAM est le moteur historique. Il a l’avantage d’être performant, mais l’inconvénient de ne pas gérer l’intégrité des données (pas de contraintes d’intégrité, pas de clés étrangères, pas de transactions...). Au contraire, InnoDB gère bien toute l’intégrité des données, mais au prix de performances moindres.

Pour un site internet, la performance est généralement un critère plus important que l’intégrité des données. MyISAM semble donc une solution à privilégier pour un site web écoconçu.

Syntaxe pour la création d’une table avec le moteur MyISAM :

CREATE TABLE nomTable ( 
... 
) ENGINE = MYISAM; 

MariaDB a également plusieurs moteurs de stockage. MyISAM est également présent. InnoDB a changé de nom pour s’appeler XtraDB. Le moteur Aria a été développé dans l’objectif...

1. Les avantages

Les procédures et les fonctions stockées ont de nombreux avantages d’un point de vue performance et donc d’un point de vue green IT.

Tout d’abord, elles permettent d’éviter de sursolliciter le réseau en limitant le nombre de requêtes envoyées au serveur de base de données. Par exemple, pour la création d’un compte utilisateur, imaginons une requête INSERT qui ajoute l’utilisateur dans une table Utilisateurs, puis une autre requête INSERT qui ajoute son adresse dans une autre table. Plutôt que d’envoyer ces deux requêtes au serveur de base de données, il est possible de créer une procédure stockée AjouterUtilisateur() qui réalise les deux insertions. Ainsi, une seule requête est envoyée à la base de données.

Ensuite, le deuxième avantage est que la procédure ou fonction stockée a déjà été analysée et compilée. Ces deux étapes n’ont donc pas à être réalisées lors de l’appel à la procédure ou fonction. Elle est directement exécutée. Cela permet de gagner encore plus en performance.

Enfin, d’un point de vue sécurité, les procédures ou fonctions stockées sont également très avantageuses. Il est possible d’accorder à l’utilisateur de la base de données des droits uniquement sur ces procédures ou fonctions stockées et non sur les tables. Ainsi, la surface d’attaque est moindre. De plus, en passant par ces procédures et fonctions stockées, il est possible de s’assurer de l’intégrité des données, même si le moteur de stockage ne le permet pas.

2. La mise en place

Illustrons ceci avec l’exemple de l’ajout d’un utilisateur. La première étape est la création des tables Utilisateurs et Adresses en utilisant phpMyAdmin :

CREATE TABLE Utilisateurs( 
  idUtilisateur  INT UNSIGNED  AUTO_INCREMENT PRIMARY KEY, 
  nom            VARCHAR(20)   NOT NULL, 
  prenom         VARCHAR(20)   NOT...

1. Le nombre de colonnes

Par facilité, en tant que développeurs, nous avons la mauvaise habitude d’utiliser des requêtes de type SELECT *. Cela est effectivement très pratique lors de la phase de développement de la base de données ou pour vérifier les données d’une table. Néanmoins, ce type d’instruction ne devrait pas se retrouver en production. D’une part, cela est plus coûteux que de lister l’ensemble des attributs de la table puisque le moteur de base de données doit commencer par les rechercher. D’autre part, nous n’avons généralement pas besoin de l’ensemble des attributs mais uniquement de certains. La projection effectuée en indiquant les attributs que doit retourner la requête diminue grandement les données transférées.

2. Le nombre de lignes

a. La clause LIMIT

Une fois que nous avons réduit le nombre de colonnes récupérées par la requête, l’autre moyen de baisser le volume des données transférées est de réduire le nombre de lignes retournées par la requête. Il est possible de mettre en place une pagination pour afficher, non pas tous les résultats d’une requête, mais seulement les n premiers, et d’afficher les suivants à la demande de l’utilisateur. L’expérience montre que généralement, seuls les premiers résultats sont utilisés et cela permet à la fois de moins solliciter le serveur de base de données et de produire des pages plus légères.

Avec MySQL ou MariaDB, il est possible de réaliser cela avec la clause LIMIT.

Syntaxe

SELECT ... 
LIMIT debut, nombre; 

La valeur nombre correspond au nombre de lignes à récupérer, et debut au nombre de lignes à sauter avant de commencer à récupérer les résultats. Par exemple, LIMIT 3, 2 récupère deux lignes après avoir sauté les trois premières, soit dans l’exemple suivant les lignes 4 et 5.