Bases de données SQL : tables, langage et moteurs d'un site

Les bases de données SQL rangent les données dans des tables reliées par des clés ; le langage SQL sert à créer ces tables, à interroger leurs données et à les modifier. Sur un hébergement web, la base relationnelle tourne sous MySQL ou MariaDB et porte le contenu dynamique.

Qu'est-ce qu'une base de données SQL ?

Une base de données SQL est une base relationnelle : les données y sont rangées dans des tables à deux dimensions, chaque ligne décrivant un élément (un article, un client, une commande) et chaque colonne une de ses propriétés (un titre, une date, un montant). Le modèle relationnel vient d'Edgar F. Codd, chercheur chez IBM, qui l'expose en 1970 dans la revue Communications of the ACM. Son idée tient dans la séparation entre la façon dont l'information est stockée sur le disque et la façon dont on la demande : le programme décrit le résultat voulu, le moteur choisit le chemin pour l'obtenir.

Les tables ne vivent pas isolées. Une clé primaire identifie chaque enregistrement de façon unique, et une clé étrangère pointe vers la clé primaire d'une autre table : c'est par ce lien qu'un commentaire sait à quel article il appartient. Le logiciel qui fait tourner l'ensemble s'appelle un système de gestion de base de données relationnelle, ou SGBDR : MySQL, MariaDB, PostgreSQL, SQLite, Microsoft SQL Server et Oracle Database en sont les plus connus.

Un SGBDR garantit aussi les propriétés dites ACID : atomicité (une transaction s'applique entière ou pas du tout), cohérence, isolation entre transactions concurrentes et durabilité après validation. Ce sont ces garanties qui expliquent l'usage des bases relationnelles en comptabilité, en banque ou dans les boutiques en ligne, partout où une donnée à moitié écrite coûterait cher. Parmi les avantages du modèle relationnel, on cite aussi la sécurité des accès, gérée compte par compte, et la possibilité d'exécuter une même recherche sur une petite ou une très grande base sans réécrire l'application.

Le langage SQL, de SEQUEL à la norme ISO

Le langage SQL, pour Structured Query Language, naît chez IBM au milieu des années 1970 : Donald Chamberlin et Raymond Boyce le décrivent en 1974 sous le nom de SEQUEL, abrégé ensuite en SQL pour une question de marque déposée. Relational Software, la future société Oracle, commercialise en 1979 l'un des premiers moteurs relationnels qui le parle. L'ANSI en fait un standard en 1986, l'ISO l'année suivante, sous la référence ISO/IEC 9075 ; l'édition en vigueur, SQL:2023, ajoute notamment des requêtes sur graphes de propriétés et de nouvelles fonctions JSON.

SQL n'est pas un langage de programmation généraliste : il est déclaratif. On écrit ce que l'on veut obtenir, sans décrire les boucles qui le produisent. On distingue usuellement quatre familles d'instructions :

• Définition des données (LDD) : CREATE, ALTER, DROP, qui bâtissent et transforment la structure ;
• Langage de manipulation des données (LMD) : SELECT, INSERT, UPDATE, DELETE, qui lisent et écrivent les enregistrements ;
• Contrôle des accès (LCD) : GRANT et REVOKE, qui donnent ou retirent des droits à un compte ;
• Contrôle des transactions : BEGIN, COMMIT, ROLLBACK, qui valident ou annulent un groupe d'écritures.

Chaque moteur ajoute ses extensions au standard : LIMIT chez MySQL, PostgreSQL et SQLite, TOP chez Microsoft SQL Server, ROWNUM dans les anciennes versions d'Oracle. Le cœur reste commun, ce qui rend les compétences transférables d'un moteur à l'autre. Dans une application web, le code PHP, Python ou Java n'exécute pas lui-même la recherche : il envoie l'instruction au SGBD, qui renvoie le résultat. Chaque utilisateur de la base reçoit seulement les droits nécessaires à son usage, en lecture seule pour un outil de statistiques par exemple.

Créer une base de données SQL et ses tables

La création d'une base de données SQL passe par l'instruction CREATE DATABASE, suivie d'une instruction CREATE TABLE par entité à stocker. Sur un hébergement mutualisé, la base se crée souvent depuis le panneau de l'hébergeur, qui attribue aussi le compte et le mot de passe ; on n'écrit alors que les tables.

Un exemple de schéma pour un petit site

L'exemple ci-dessous crée une base pour un blog, avec des auteurs et leurs articles. Chaque article référence son auteur par une clé étrangère.

CREATE DATABASE blog CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
USE blog;

CREATE TABLE auteurs (
  id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  nom VARCHAR(80) NOT NULL,
  prenom VARCHAR(80) NOT NULL,
  email VARCHAR(190) NOT NULL UNIQUE
) ENGINE=InnoDB;

CREATE TABLE articles (
  id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  auteur_id INT UNSIGNED NOT NULL,
  titre VARCHAR(200) NOT NULL,
  publie_le DATETIME NOT NULL,
  FOREIGN KEY (auteur_id) REFERENCES auteurs(id)
) ENGINE=InnoDB;

Plusieurs choix de cet exemple méritent une explication. Le jeu de caractères utf8mb4 stocke tous les caractères Unicode, émojis compris, ce que l'ancien utf8 de MySQL ne fait pas. NOT NULL interdit qu'un champ reste vide, UNIQUE empêche deux comptes avec le même email, et la contrainte FOREIGN KEY refuse un article dont l'auteur n'existe pas. La longueur 190 pour l'email n'a rien d'arbitraire : elle tient sous la limite d'index des anciennes versions d'InnoDB en utf8mb4.

Faire évoluer la structure sans tout recréer

Une base de données SQL vivante change de forme avec son site. L'instruction ALTER TABLE ajoute une colonne, en modifie le type ou pose un index sans perdre le contenu existant :

ALTER TABLE articles ADD resume TEXT NULL AFTER titre;
ALTER TABLE articles ADD INDEX idx_publie (publie_le);

Sur un gros volume, cette opération peut verrouiller l'écriture pendant de longues minutes selon le moteur et la version : on la lance de préférence à une heure creuse, et toujours après une sauvegarde.

Les types de données d'une colonne

Les types de données fixent ce qu'une colonne accepte et la place qu'elle occupe. Le standard SQL définit des familles communes, que chaque SGBDR décline avec ses propres noms et limites. Le bon type évite des erreurs silencieuses : un prix stocké en FLOAT accumule des écarts d'arrondi, une date stockée en texte se trie mal.

SQLite fait exception : son typage est dynamique, une colonne déclarée INTEGER accepte un texte, et la déclaration ne sert que d'affinité. C'est l'une des difficultés quand on doit convertir des tables SQLite vers un serveur MySQL, où la même valeur peut être refusée. Pour des documents structurés, le choix entre un BLOB et une colonne JSON native dépend de ce que l'on veut interroger dans le document.

Interroger une base de données en SQL

Interroger une base de données SQL revient à écrire une requête SELECT : la clause SELECT nomme les colonnes voulues, FROM la table source, WHERE filtre les enregistrements, ORDER BY trie et LIMIT borne le nombre de résultats. L'insertion et la mise à jour suivent une syntaxe aussi lisible.

INSERT INTO auteurs (nom, prenom, email) VALUES ('Martin', 'Claire', 'claire@exemple.fr');

SELECT titre, publie_le
FROM articles
WHERE publie_le >= '2026-01-01'
ORDER BY publie_le DESC
LIMIT 10;

UPDATE articles SET titre = 'Nouveau titre' WHERE id = 42;

La clause GROUP BY regroupe les enregistrements pour calculer un total, une moyenne ou un compte par groupe, et HAVING filtre ces groupes après calcul. Les jointures croisent plusieurs tables : INNER JOIN ne garde que les correspondances, LEFT OUTER JOIN conserve aussi les éléments de gauche sans correspondance.

SELECT a.nom, a.prenom, COUNT(ar.id) AS nb_articles
FROM auteurs a
LEFT OUTER JOIN articles ar ON ar.auteur_id = a.id
GROUP BY a.id, a.nom, a.prenom
HAVING COUNT(ar.id) >= 1
ORDER BY nb_articles DESC;

Cette requête liste chaque auteur avec son nombre d'articles. Sur une grosse base, une jointure mal indexée examine des millions de combinaisons : la méthode pour optimiser une jointure externe gauche commence par lire le plan d'exécution avec EXPLAIN.

Pourquoi une condition WHERE colonne = NULL ne renvoie-t-elle rien ?

En SQL, NULL signifie « valeur inconnue » : toute comparaison avec lui donne un résultat inconnu, jamais vrai. Il faut écrire WHERE colonne IS NULL, ou IS NOT NULL pour l'inverse.

Pourquoi MySQL refuse-t-il une colonne absente du GROUP BY ?

Depuis la version 5.7.5, le mode ONLY_FULL_GROUP_BY est actif par défaut : chaque colonne du SELECT doit figurer dans le GROUP BY ou passer par une fonction d'agrégat (COUNT, SUM, MAX). Sans cette règle, le serveur renverrait une valeur prise au hasard dans le groupe.

Comment éviter un UPDATE qui modifie toute la table ?

Un UPDATE ou un DELETE sans WHERE touche tous les enregistrements. Le client mysql propose l'option --safe-updates, qui refuse ces instructions sans condition sur une clé ; ouvrir une transaction avec BEGIN permet aussi de vérifier l'effet avant COMMIT.

Les systèmes de gestion de base de données les plus répandus

Les systèmes de gestion de base de données relationnelle partagent le langage SQL mais diffèrent par leur licence, leur architecture et leur terrain de prédilection. Le tableau compare les six moteurs que l'on croise le plus souvent, du petit site à l'entreprise.

MySQL apparaît en 1995 ; Sun Microsystems rachète son éditeur en 2008, puis Oracle reprend Sun en 2010. Michael Widenius, l'un de ses créateurs, lance MariaDB en 2009 pour garder une branche indépendante. PostgreSQL descend du projet Postgres de l'université de Berkeley, dirigé par Michael Stonebraker. Microsoft SQL Server, longtemps réservé à Windows, fonctionne aussi sous Linux depuis sa version 2017.

MySQL ou MariaDB sur un hébergement

MariaDB garde la syntaxe de MySQL, si bien qu'un site écrit pour l'un fonctionne en général sur l'autre ; leurs calendriers de versions divergent pourtant. Selon les avis de fin de support publiés sur mysql.com, MySQL 8.0 arrive en fin de vie en avril 2026 et les branches à long terme sont désormais 8.4 et 9.7. Côté MariaDB, la politique de maintenance de mariadb.org place la 10.6 hors support communautaire depuis le 6 juillet 2026 et retient comme versions à long terme la 10.11, la 11.4, la 11.8 et la 12.3, disponible depuis le 28 mai 2026. L'hébergeur fixe la version du serveur : elle se lit dans phpMyAdmin ou avec la requête SELECT VERSION(); et c'est elle, non la bibliothèque cliente de PHP, qui détermine les fonctions SQL utilisables.

SQL, NoSQL et bases dans le cloud

Une base de données SQL impose un schéma : chaque table déclare ses colonnes et leurs types avant de recevoir le moindre enregistrement. Les bases NoSQL (MongoDB pour les documents, Redis pour les paires clé-valeur, Cassandra pour les colonnes larges) relâchent cette contrainte pour gagner en souplesse ou en répartition sur de nombreux serveurs. Le choix suit la forme des données : des entités fortement liées (clients, factures, lignes de facture) appellent le modèle relationnel ; des documents hétérogènes, un cache ou des flux massifs de big data peuvent s'en passer. Beaucoup de sites combinent les deux, par exemple MySQL pour le contenu et Redis pour les sessions.

Le cloud computing a aussi changé la façon d'exploiter une base. Les grands fournisseurs proposent des moteurs SQL gérés : Azure SQL Database chez Microsoft, Amazon RDS et Aurora chez AWS, Cloud SQL chez Google. Le fournisseur prend en charge les mises à jour, la réplication et les sauvegardes ; l'équipe garde la conception du schéma et l'optimisation des requêtes, que nul service ne fait à sa place. Pour un blog ou une vitrine, la base fournie avec l'hébergement mutualisé reste la solution la plus courante : on utilise un service géré quand le besoin de disponibilité ou de montée en charge le justifie, et l'équipe qui l'utilise garde la main sur ses données.

Gérer une base de données au quotidien

La gestion d'une base de données SQL sur un hébergement se résume à trois gestes : se connecter, sauvegarder, surveiller les performances. La connexion demande quatre informations : le nom d'hôte du serveur, le nom de la base, le compte et son mot de passe. Sur un hébergement partagé, l'hôte n'est pas toujours localhost ; c'est le premier élément à contrôler quand un CMS affiche une erreur d'établissement de connexion. L'accès depuis l'extérieur est souvent fermé par défaut ; quand il est possible, un tunnel SSH vaut mieux qu'un port ouvert à tout internet.

Exporter et réimporter avec mysqldump

mysqldump --single-transaction -h serveur-sql -u compte -p nom_base > sauvegarde.sql
mysql -h serveur-sql -u compte -p nom_base < sauvegarde.sql

Ces deux commandes exportent puis réimportent une base. Elles contournent les échecs de phpMyAdmin sur les gros volumes, qui tiennent le plus souvent à la durée d'exécution ou à la taille d'envoi permises par PHP. L'option --single-transaction produit une copie cohérente des tables InnoDB sans les bloquer pendant l'export. Une tâche planifiée peut lancer cette commande chaque nuit : la crontab d'un serveur Linux sert exactement à cela.

Choisir un moteur de stockage et accélérer les lectures

Sous MySQL et MariaDB, chaque table repose sur un moteur de stockage. La documentation officielle présente InnoDB comme le moteur par défaut et le plus polyvalent : il gère les transactions, les clés étrangères et le verrouillage enregistrement par enregistrement. MyISAM, plus ancien, ignore les transactions et verrouille l'ensemble à chaque écriture ; MEMORY garde tout en mémoire vive et perd son contenu au redémarrage. Le détail pour choisir entre MyISAM, InnoDB et MEMORY dépend surtout du rapport entre lectures et écritures.

Une requête lente s'analyse avec EXPLAIN placé devant le SELECT : la colonne key montre l'index retenu, la colonne rows le nombre d'enregistrements examinés. Un index sur les champs du WHERE et sur ceux des jointures règle la majorité des cas. Certaines tournures restent coûteuses quoi qu'on fasse, comme le tri aléatoire, qu'il vaut mieux optimiser autrement qu'avec ORDER BY RAND(). Les automatismes côté serveur, enfin, ont leur outil : les déclencheurs (triggers) écrits en SQL conviennent à une règle courte, comme tenir une date de mise à jour.

Apprendre SQL : un savoir qui dépasse le développement web

L'apprentissage du langage SQL sert bien au-delà de l'administration d'un site. Les métiers de la data (data analyst, data scientist, ingénieur de données) l'utilisent chaque jour pour extraire et agréger l'information avant toute analyse, et la plupart des outils de data science ou d'informatique décisionnelle génèrent du SQL en arrière-plan. Même les projets d'intelligence artificielle s'appuient sur des bases relationnelles pour préparer et tracer leurs jeux de données.

Pour s'exercer sans rien installer, SQLite suffit : un seul fichier, aucun serveur, et un interpréteur en ligne de commande fourni avec la plupart des systèmes Linux et macOS. Pour un débutant, la formation la plus simple consiste à apprendre par l'utilisation : la plupart des distributions fournissent SQLite à l'installation, et l'utilisation quotidienne d'une base réelle forme plus vite qu'une liste de commandes. Un parcours raisonnable enchaîne SELECT et WHERE sur une seule table, puis GROUP BY et les fonctions d'agrégat, puis les jointures, et seulement ensuite la création de schéma et les index. Les cours en ligne gratuits ne manquent pas, mais l'exercice le plus formateur reste d'interroger une base que l'on connaît, celle de son propre CMS par exemple, sur une copie et jamais sur la production. La configuration de PHP qui dialogue avec cette base relève de la rubrique PHP et serveurs.

Sources : E. F. Codd, « A Relational Model of Data for Large Shared Data Banks », Communications of the ACM, 1970 ; norme ISO/IEC 9075:2023 ; avis de fin de support de MySQL sur mysql.com ; politique de maintenance de MariaDB sur mariadb.org ; manuel de référence MySQL 8.4 (moteurs de stockage, mode ONLY_FULL_GROUP_BY), consultés le 14 octobre 2026.