Base de données
L’ensemble organisé des données et de leurs règles.
Du problème métier à la capacité technique
SQL ne sert pas seulement à lire des données.
Découvrez comment une base relationnelle peut structurer, contrôler, modifier, automatiser, sécuriser et accélérer les informations d’une organisation.
Pratique disponibleExplication disponibleLaboratoire en préparation
Quatre notions différentes
Langage, données et logiciel ne sont pas synonymes.
SGBD
Le logiciel qui stocke, contrôle et exécute les opérations.
Serveur
L’environnement qui fait fonctionner un service de base pour ses clients.
SQL
Le langage utilisé par plusieurs SGBD, avec un socle et des dialectes.
PostgreSQL, MySQL et SQL Server sont des SGBD. Ils utilisent SQL, mais leurs types, fonctions, procédures, outils d’administration et certaines syntaxes diffèrent.
12 familles
Commencez par le problème, puis choisissez l’outil.
Explication disponibleDébutant
Modéliser
- Problème métier
- Les clients, commandes et paiements sont mélangés ou recopiés.
- Explication simple
- Tables, types, schémas, clés et relations donnent une place et un sens à chaque fait.
- Exemple
- Une commande garde id_client au lieu de recopier le nom et l’adresse du client.
- Dialecte
- SQL commun ; types détaillés par SGBD
Pratique disponibleDébutant à avancé
Interroger
- Problème métier
- Une équipe veut une réponse reproductible plutôt qu’un total calculé manuellement.
- Explication simple
- SELECT, filtres, agrégations, jointures, fonctions fenêtre et CTE transforment une question en résultat.
- Exemple
- Calculer le chiffre d’affaires par ville et classer le meilleur résultat.
- Dialecte
- Large socle SQL commun
Explication disponibleDébutant / intermédiaire
Modifier
- Problème métier
- Une application doit enregistrer une vente, corriger une adresse ou supprimer un brouillon.
- Explication simple
- INSERT ajoute, UPDATE modifie, DELETE retire ; UPSERT ou MERGE traite un conflit selon le moteur.
- Exemple
- Mettre à jour le téléphone du client identifié sans toucher aux autres lignes.
- Dialecte
- INSERT/UPDATE/DELETE communs ; UPSERT/MERGE dialectal
Explication disponibleDébutant / intermédiaire
Garantir l’intégrité
- Problème métier
- Un prix négatif, un e-mail dupliqué ou une commande orpheline entre dans la base.
- Explication simple
- Types, NOT NULL, UNIQUE, CHECK, PRIMARY KEY et FOREIGN KEY refusent les états invalides au bon endroit.
- Exemple
- CHECK (prix >= 0) refuse un prix négatif avant qu’un rapport le découvre.
- Dialecte
- SQL commun avec nuances
Laboratoire en préparationIntermédiaire
Gérer les transactions
- Problème métier
- Une commande est créée mais le paiement échoue, laissant la base dans un état incomplet.
- Explication simple
- Une transaction regroupe les modifications ; COMMIT confirme, ROLLBACK annule et SAVEPOINT permet un retour partiel.
- Exemple
- Enregistrer la commande et son règlement ensemble, ou n’enregistrer aucun des deux.
- Dialecte
- Socle SQL ; isolation et concurrence dépendent du SGBD
Explication disponibleIntermédiaire
Créer des vues
- Problème métier
- Trois rapports redéfinissent différemment le même chiffre d’affaires mensuel.
- Explication simple
- Une vue nomme une requête réutilisable ; une vue matérialisée conserve un résultat à rafraîchir.
- Exemple
- Exposer ventes_mensuelles à plusieurs outils sans recopier la requête.
- Dialecte
- Vues largement communes ; matérialisation selon moteur
Laboratoire en préparationIntermédiaire / avancé
Automatiser avec fonctions, procédures et triggers
- Problème métier
- Chaque changement de prix doit laisser une trace, quel que soit le processus appelant.
- Explication simple
- Une fonction encapsule un calcul, une procédure exécute une opération et un trigger réagit à un événement de table.
- Exemple
- Après UPDATE du prix, enregistrer OLD.prix et NEW.prix dans une table d’historique.
- Dialecte
- Très dépendant du SGBD ; exemples futurs PostgreSQL
Explication disponibleIntermédiaire
Optimiser avec index et EXPLAIN
- Problème métier
- La recherche d’un compte par e-mail ralentit lorsque la table grandit.
- Explication simple
- EXPLAIN montre le plan choisi ; un index peut accélérer une lecture en ajoutant un coût de stockage et d’écriture.
- Exemple
- Comparer le plan avant et après un index sur lower(email).
- Dialecte
- Principes communs ; plans propres au SGBD
Explication disponibleIntermédiaire
Sécuriser avec rôles et permissions
- Problème métier
- Un outil de reporting doit lire certaines vues sans pouvoir modifier les tables.
- Explication simple
- Utilisateurs, rôles, GRANT, REVOKE et parfois la sécurité des lignes appliquent le moindre privilège.
- Exemple
- Accorder SELECT sur une vue au rôle reporting et refuser UPDATE sur la table source.
- Dialecte
- SQL + administration ; RLS selon SGBD
Explication disponibleIntermédiaire / avancé
Travailler avec JSON, texte ou géographie
- Problème métier
- Certaines données sont semi-structurées, textuelles ou spatiales.
- Explication simple
- JSON/JSONB, recherche plein texte, types géographiques et extensions élargissent les usages lorsque le moteur les supporte.
- Exemple
- Conserver des attributs variables dans JSONB tout en indexant les clés souvent recherchées.
- Dialecte
- Fortement dépendant du moteur et des extensions
Explication disponibleAvancé
Administrer, sauvegarder et répliquer
- Problème métier
- Le service doit être restaurable, surveillé et disponible malgré une panne.
- Explication simple
- Sauvegardes, restauration, réplication, supervision et haute disponibilité relèvent principalement de l’administration du SGBD et de l’infrastructure.
- Exemple
- Tester une restauration à partir d’un dump plutôt que supposer qu’une sauvegarde est exploitable.
- Dialecte
- Outils et procédures propres au SGBD
Explication disponibleDébutant à avancé
Alimenter applications et outils BI
- Problème métier
- Une application, une API et Power BI doivent utiliser des définitions cohérentes.
- Explication simple
- SQL sélectionne, contrôle et prépare les données ; connecteurs, API et pipelines ETL/ELT les déplacent ou les exposent.
- Exemple
- Préparer une vue au grain commande pour un modèle Power BI sans doubler les montants.
- Dialecte
- SQL dans une architecture plus large
Choisir l’outil le plus simple
Quand ne pas utiliser un trigger ?
Une contrainte suffit
Pour refuser un prix négatif, CHECK est plus visible et plus directe qu’une logique déclenchée.
La logique deviendrait cachée
Un trigger s’exécute sans apparaître dans la requête appelante. Il peut surprendre et compliquer le débogage.
Le volume est important
Une action par ligne peut ralentir une modification massive. Le coût doit être mesuré sur le cas réel.
La récursion est possible
Un trigger qui modifie la même table peut se rappeler lui-même. Il faut une conception et des protections explicites.
Cas adaptés : audit, historisation et certaines automatisations strictement liées à un événement de données, après comparaison avec une contrainte ou une logique applicative.
Vous partez de zéro ?
Commencez par une situation sans code, puis exécutez votre première requête en moins de 45 minutes.