Quels sont les 4 sous-langages de SQL ?

On lance une requête SELECT pour extraire des données, puis un CREATE TABLE pour structurer un nouveau schéma, et enfin un GRANT pour ouvrir les accès à un collègue. Trois commandes, trois intentions distinctes, et pourtant toutes écrites en SQL. Pour s’y retrouver, on découpe le langage SQL en sous-langages, chacun regroupant les commandes qui partagent la même finalité.

Pourquoi SQL n’est pas un bloc monolithique de commandes

Sur le terrain, quand on administre une base de données en production, on ne mélange pas les opérations de structure avec celles qui touchent aux données elles-mêmes. Un ALTER TABLE mal placé pendant un pic de requêtes peut verrouiller une table entière. Séparer les commandes par catégorie fonctionnelle n’est pas un exercice académique, c’est une précaution opérationnelle.

A découvrir également : Comment puis-je créer un site Web avec mon téléphone ?

La classification la plus répandue distingue quatre sous-langages : DDL, DML, DQL et DCL. Ce découpage ne figure pas tel quel dans un standard unique. La documentation de PostgreSQL, par exemple, liste ses instructions SQL sans les ranger sous ces étiquettes. Le découpage en quatre catégories reste une convention pédagogique et professionnelle largement adoptée, même si certaines présentations y ajoutent un cinquième groupe (TCL, pour le contrôle transactionnel).

Analyste de données expliquant les sous-langages SQL sur un tableau blanc dans une salle de formation

A lire également : Quel est le moyen le plus sécurisé pour payer sur internet ?

DDL – commandes SQL de définition de structure

Quand on crée un projet depuis zéro, la première étape consiste à poser le squelette : tables, colonnes, index, contraintes. C’est le rôle du DDL (Data Definition Language), le sous-langage qui agit sur la structure de la base de données.

Commandes principales du DDL

  • CREATE TABLE : crée une nouvelle table avec ses colonnes, ses types et ses contraintes (clé primaire, unicité, valeurs par défaut).
  • ALTER TABLE : modifie une table existante, que ce soit pour ajouter une colonne, changer un type ou supprimer une contrainte.
  • DROP TABLE : supprime une table et toutes les données qu’elle contient, sans possibilité de retour arrière sur la plupart des moteurs.

Un point souvent ignoré : le comportement transactionnel du DDL varie selon les SGBD. PostgreSQL permet d’exécuter un CREATE TABLE à l’intérieur d’une transaction et de l’annuler avec ROLLBACK. D’autres moteurs provoquent une validation implicite dès qu’une commande DDL est exécutée, ce qui rend l’annulation impossible. En environnement de production, cette différence change radicalement la façon dont on planifie une migration de schéma.

DML et DQL – manipuler et interroger les données

Une fois la structure en place, on travaille avec le contenu. Le DML (Data Manipulation Language) couvre les opérations d’écriture sur les lignes d’une table : INSERT pour ajouter des enregistrements, UPDATE pour les modifier, DELETE pour les supprimer.

DQL : SELECT mérite-t-il sa propre catégorie ?

La commande SELECT est techniquement une opération de lecture, pas d’écriture. Certaines classifications la rangent dans le DML, d’autres la placent dans un sous-langage dédié : le DQL (Data Query Language). DQL isole la lecture des données de leur modification, ce qui reflète mieux la réalité du terrain. En pratique, un développeur qui n’a besoin que de consulter une base reçoit des droits en lecture seule, pas en écriture.

C’est dans le DQL qu’on retrouve les clauses les plus utilisées au quotidien : WHERE pour filtrer les lignes, JOIN pour croiser plusieurs tables, ORDER BY pour trier le résultat. La maîtrise de ces clauses constitue le socle du travail avec une base relationnelle.

Exemple concret d’une requête DQL

Pour récupérer les commandes d’un client spécifique avec le nom du produit associé, on écrit une jointure entre la table des commandes et celle des produits :

SELECT commandes.id, produits.nom FROM commandes JOIN produits ON commandes.produit_id = produits.id WHERE commandes.client_id = 42;

Cette requête ne modifie rien. Elle interroge deux tables, applique un filtre et renvoie un résultat. C’est du DQL pur.

Deux administrateurs de bases de données collaborant devant un terminal SQL dans une salle de serveurs

DCL – contrôle des droits d’accès SQL

Sur un serveur partagé entre plusieurs équipes, la question des permissions se pose immédiatement. Le DCL (Data Control Language) regroupe les commandes qui gèrent les droits des utilisateurs sur les objets de la base.

Deux commandes concentrent la quasi-totalité du DCL :

  • GRANT : attribue un droit (lecture, écriture, suppression) à un utilisateur ou un rôle sur une table, une vue ou l’ensemble d’un schéma.
  • REVOKE : retire un droit précédemment accordé.

On sous-estime souvent l’impact du DCL. Un GRANT ALL trop large donné à un compte applicatif peut exposer des données sensibles. À l’inverse, des droits trop restrictifs bloquent les requêtes en production et génèrent des tickets de support en cascade. Le DCL est le sous-langage qui traduit la politique de sécurité en règles techniques.

TCL et les limites de la classification en quatre sous-langages SQL

La réalité des SGBD ne se plie pas toujours à un découpage en quatre catégories nettes. Les commandes COMMIT, ROLLBACK et SAVEPOINT contrôlent la validation et l’annulation des transactions. Elles forment ce qu’on appelle le TCL (Transaction Control Language), un cinquième sous-langage que beaucoup de documentations reconnaissent sans l’inclure dans le schéma classique.

La frontière entre ces catégories dépend du standard, du manuel ou du SGBD considéré. Les retours varient sur ce point : certains formateurs intègrent le TCL au DML, d’autres en font un groupe à part entière. Cette fluidité n’est pas un défaut de la classification, elle reflète simplement le fait que SQL a été conçu comme un langage déclaratif unifié, pas comme quatre langages distincts assemblés après coup.

Retenir la logique derrière chaque catégorie reste plus utile que mémoriser des listes de commandes. DDL structure, DML et DQL travaillent sur les données (en écriture et en lecture), DCL sécurise les accès, et TCL garantit la cohérence des opérations groupées. Quand on sait dans quelle catégorie tombe une commande, on sait aussi quel type de risque elle porte et quel niveau de privilège elle exige.