SQL et MariaDB ne désignent pas la même chose
SQL est un langage utilisé pour interroger et manipuler des données relationnelles. MariaDB est un système qui stocke ces données et exécute les requêtes. Apprendre les deux ensemble permet de relier une instruction à un résultat, plutôt que de mémoriser seulement sa forme.
Dans notre exemple, la table livres possède trois colonnes : id, titre et disponible. La valeur 1 de disponible signifie ici que le livre est disponible ; c’est une convention de cet exemple, pas une règle imposée à toutes les bases. Les titres sont fictifs et aucune donnée de compte Stuudium n’est utilisée.
Une requête complète, dans une base d’essai
Exécute ce code uniquement dans ta propre base de travail vide. Il crée une table dédiée à l’exemple, puis affiche les titres disponibles. Si la table existe déjà, choisis un autre nom : ne supprime pas une table pour suivre un tutoriel sans savoir ce qu’elle contient.
CREATE TABLE livres_demo (
id INT PRIMARY KEY,
titre VARCHAR(100) NOT NULL,
disponible BOOLEAN NOT NULL
);
INSERT INTO livres_demo (id, titre, disponible) VALUES
(1, 'Atelier des réseaux', 1),
(2, 'Carnet des algorithmes', 0),
(3, 'Initiation aux données', 1);
SELECT titre
FROM livres_demo
WHERE disponible = 1
ORDER BY titre ASC;Comprendre le résultat, ligne par ligne
SELECT titre demande une colonne. FROM livres_demo indique la table. WHERE disponible = 1 garde les lignes correspondant à la condition. ORDER BY titre ASC demande un tri ascendant. Le résultat de cet exemple contient « Atelier des réseaux » et « Initiation aux données », pas le carnet indisponible.
Sans ORDER BY, ne compte pas sur l’ordre dans lequel les lignes ont été insérées. Une requête correcte doit exprimer le tri dont elle a besoin. Lorsque le tri comporte des égalités, ajoute un second critère si tu as besoin d’un ordre déterministe.
Pour te vérifier, change uniquement le filtre en disponible = 0 et prédis le résultat avant de l’exécuter. Change ensuite SELECT titre en SELECT id, titre. Ces petites variations montrent si tu comprends le rôle de chaque clause, sans te demander de construire immédiatement une application entière.
L’ordre conseillé pour la suite
Une fois cette requête comprise, passe aux clés primaires et étrangères, puis aux jointures entre deux tables. Pour une bibliothèque, un emprunt reliera un livre et un lecteur : cette nouvelle question justifie la jointure au lieu de l’apprendre hors contexte.
L’administration vient ensuite : comptes et permissions, sauvegarde et restauration, transactions, puis index et observation des requêtes. Une sauvegarde non restaurée au moins une fois dans un environnement d’essai n’est pas une preuve que tu sais récupérer les données.
- Prévoir le résultat avant d’exécuter une requête.
- Comparer le résultat avec les données d’origine.
- Noter la cause d’un écart avant de modifier plusieurs clauses à la fois.