Formation SQL : interroger et modifier une base sans risque

SQL est le langage des bases de données relationnelles : on y décrit les données que l'on veut lire ou modifier, et le moteur trouve comment le faire. Un DevOps le croise partout, pour vérifier un inventaire, corriger une donnée en production, passer une migration, diagnostiquer une application lente ou écrire un script de supervision. Cette formation s'adresse à qui doit interroger et modifier une base sans risque, sans devenir administrateur de base de données. Elle travaille sous PostgreSQL 18 et enseigne le langage, ses pièges silencieux, puis les gestes qui rendent une modification sûre et un script fiable.

Ce que vous allez apprendre

Lire le schéma d'une base et écrire les requêtes qui y répondent juste.
Modifier des données de façon vérifiable et réversible.
Comprendre ce qui se passe quand plusieurs sessions travaillent en même temps.
Diagnostiquer une requête lente et utiliser SQL en script sans injection.

Qu'est-ce que SQL ?

SQL (Structured Query Language) interroge des tables : des lignes, toutes de même forme, faites de colonnes typées. On ne dit pas comment parcourir les données, on dit ce qu'on veut :

SELECT hostname, ram_gb
FROM servers
WHERE environment = 'production' AND active
ORDER BY ram_gb DESC;

Le moteur choisit seul la façon d'y répondre, en lisant toute la table ou en passant par un index : c'est ce qu'on appelle un langage déclaratif. Les tables se relient entre elles par des clés : un service porte l'identifiant de son serveur, et une jointure les réunit. Le même langage lit (SELECT), modifie (INSERT, UPDATE, DELETE) et décrit la structure (CREATE, ALTER).

D'où vient SQL, et pourquoi dure-t-il ?

En 1970, Edgar F. Codd, chercheur chez IBM, publie A Relational Model of Data for Large Shared Data Banks : les données y sont rangées en relations, des tables, manipulées par des opérations mathématiques plutôt que par des pointeurs à suivre. Au début des années 1970, au laboratoire IBM de San Jose, Donald Chamberlin et Raymond Boyce en tirent un langage, SEQUEL, renommé SQL parce que le premier nom était une marque déposée.

Le langage devient une norme ANSI en 1986, puis ISO en 1987 ; la version en vigueur est SQL:2023, publiée sous la référence ISO/IEC 9075:2023. Cette normalisation explique sa longévité : un SELECT écrit il y a trente ans fonctionne encore. Elle a ses limites : chaque moteur ajoute ses extensions et interprète certains points à sa façon, et la formation mesure ces écarts quand ils changent un résultat.

Où rencontre-t-on SQL ?

Partout où des données structurées doivent être lues de façon fiable par plusieurs programmes. Pour un DevOps, trois familles de moteurs dominent :

Moteur	Où on le rencontre	Particularité qui compte
PostgreSQL	applications, outils d'infrastructure, offres managées	typage strict, DDL transactionnel
MySQL et MariaDB	applications web, CMS	DDL non transactionnel, `LIKE` insensible à la casse
SQLite	fichier local, outils embarqués, tests	clés étrangères désactivées par défaut, typage souple

La formation travaille sous PostgreSQL, le moteur des guides d'administration du site et le plus exigeant des trois : ce qu'il refuse, SQLite l'accepte souvent en silence. Les différences avec MySQL et SQLite sont mesurées et signalées dans chaque leçon où elles changent un résultat.

Le programme de la formation

Toutes les leçons travaillent sur la même base fil rouge, infra, qui décrit une plateforme d'infrastructure : serveurs, équipe, services, déploiements et alertes. Elle tourne dans un conteneur PostgreSQL épinglé, et un script la remet dans son état initial après chaque exercice. Le plan complet, avec votre progression, est sur la page Mon parcours.

Le premier module, « Lire », apprend à lire un schéma, à écrire les requêtes de base et à se méfier de NULL, qui fausse les résultats sans erreur.

Le deuxième, « Interroger », croise les tables avec les jointures, résume avec les agrégations, et structure les requêtes longues avec les CTE et le fenêtrage.

Le troisième, « Modifier sans risque », enseigne les modifications avec leur garde-fou, les transactions et la concurrence, puis l'évolution du schéma d'une base en production.

Le quatrième, « Diagnostiquer et outiller », explique une requête lente avec les index et EXPLAIN, rend psql fiable dans un script, et neutralise l'injection SQL.

L'administration du serveur, installation, configuration, sauvegarde et réplication, vit dans les guides PostgreSQL et MySQL ; la formation y renvoie sans les redire.

Mon retour d'expérience

Une requête SQL qui échoue ne coûte rien : on lit le message, on corrige. Ce qui coûte cher, ce sont les requêtes qui réussissent avec une réponse fausse. En préparant cette formation, j'ai mesuré sur la base fil rouge un filtre « pas en HTTPS » qui oublie trois services sur quinze à cause de NULL, un NOT IN qui rend zéro ligne au lieu de sept, un LEFT JOIN qui perd trois serveurs, un taux de réussite affiché à 0 % au lieu de 88 % par division entière, et un fichier SQL en échec dont psql sort avec le code 0. L'ancienne version de cette série tournait sous SQLite, qui laissait passer une partie de ces erreurs et désactive les clés étrangères par défaut. Chaque exemple a donc été rejoué sous PostgreSQL, et chaque silence est enseigné comme tel.

Ce que cette formation défend

Lire le schéma avant d'écrire. Types, NULL permis et contraintes disent déjà ce qu'une requête peut rater.
NOT EXISTS plutôt que NOT IN. Un seul NULL dans la sous-requête vide le résultat de NOT IN.
BEGIN avant toute modification en production. Le compte de lignes se lit avant le COMMIT, pas après.
-v ON_ERROR_STOP=1 sur tout fichier SQL. Sans lui, une migration en échec sort en succès.
Des paramètres, jamais de concaténation. Une valeur variable entre dans une requête par un paramètre, et par rien d'autre.

Ce que je vous interdis

Un UPDATE ou un DELETE lancé en autocommit sans SELECT préalable avec le même WHERE.
Une période filtrée par BETWEEN sur des horodatages : le dernier jour disparaît.
Un ALTER TABLE en production sans lock_timeout : en attente, il bloque toute l'application.
EXPLAIN ANALYZE sur un DELETE hors transaction : il supprime vraiment.

Outils et versions de référence

Les mesures de la formation ont été produites le 7 octobre 2026 avec les versions suivantes, épinglées dans le lab :

Outil	Version	Rôle dans la formation
PostgreSQL	18.6	moteur de référence, client `psql` du conteneur
SQLite	3.53.4	comparaisons de comportement
MySQL	8.4.11 LTS	comparaisons de comportement
psycopg	3.3.6	requêtes paramétrées depuis Python

À retenir

SQL décrit les données voulues ; le moteur choisit comment les obtenir.
Né du modèle relationnel de Codd en 1970, normalisé depuis 1986, il en est à SQL:2023.
La formation travaille sous PostgreSQL, le plus strict : ce qu'il refuse, SQLite l'accepte souvent en silence.
Le danger n'est pas l'erreur, c'est la réponse fausse : NULL, jointures, divisions, codes de retour.
Une modification sûre passe par une transaction, un script fiable par ON_ERROR_STOP et des paramètres.