Versions de la norme SQL et dialectes SQL

Leçon 1.8 · Temps de lecture : ~8 min

La norme SQL est la spécification internationale du langage SQL, publiée par l'ISO et l'ANSI sous le nom ISO/IEC 9075. La première version date de 1986, la plus récente est SQL:2023. Dans cette leçon, vous verrez ce qu'a ajouté chaque version de la norme, de la syntaxe explicite des JOIN au JSON et aux requêtes de graphes, et pourquoi chaque base de données parle son propre dialecte SQL. À la fin, vous saurez quelles parties d'une requête sont portables et lesquelles dépendent de la base.

Dans la leçon précédente, vous avez vu ce qu'est SQL et comment se construit une requête de base. SQL n'appartient pas à un seul éditeur : son cœur est défini par une norme, et chaque base de données implémente cette norme à sa façon.

Cela explique une surprise fréquente : une requête qui fonctionne dans PostgreSQL peut échouer dans SQL Server ou MySQL. Connaître la norme aide à écrire des requêtes qui passent d'une base à l'autre avec moins de modifications.

Qu'est-ce que la norme SQL ?

SQL a été créé chez IBM dans les années 1970. Au milieu des années 1980, plusieurs éditeurs avaient leur propre version du langage ; l'ANSI, puis l'ISO, ont donc publié une spécification commune : SQL-86. Depuis, la norme est révisée régulièrement par le comité ISO/IEC JTC 1/SC 32.

La norme est volumineuse et se compose de plusieurs parties. La partie 2, SQL/Foundation, définit le cœur du langage : tables, requêtes, modification des données, transactions. D'autres parties couvrent le XML, les données externes, les tableaux multidimensionnels et, depuis 2023, les graphes de propriétés.

Quelques points utiles :

• La norme définit un ensemble obligatoire de fonctionnalités appelé Core SQL ; tout le reste est facultatif.
• Aucune base de données n'implémente toute la norme, et chacune ajoute ses propres extensions.
• Les documents de la norme sont payants : en pratique, on apprend SQL avec la documentation des bases de données.

Les versions de la norme SQL et ce qu'elles ont apporté

Chaque version a conservé les précédentes et ajouté de nouvelles fonctionnalités. Le tableau liste celles que vous rencontrerez dans ce cours :

SQL-92 reste un repère important : il a fixé la syntaxe que presque toutes les bases relationnelles prennent en charge. Mais la norme moderne est bien plus riche, et la plupart des fonctionnalités du SQL analytique sont apparues après 1999.

Les nouveautés de SQL:2023 : JSON et requêtes de graphes

SQL:2023 permet à une même base de travailler avec des données relationnelles, des documents et des graphes dans la même requête.

Le type de données JSON

SQL:2016 a ajouté des fonctions qui lisent du JSON stocké sous forme de texte. SQL:2023 ajoute un véritable type JSON : la base vérifie que la colonne contient du JSON valide et peut le stocker sous une forme binaire efficace. MySQL, MariaDB et PostgreSQL (jsonb) avaient leurs propres types JSON avant la norme ; Oracle, à partir de la version 21c, suit le type normalisé.

Les requêtes sur graphes de propriétés (SQL/PGQ)

Un graphe de propriétés est un ensemble de sommets et d'arêtes, par exemple des acteurs et des films reliés par « a joué dans ». Les bases de graphes comme Neo4j interrogent ces données avec des langages spécifiques. SQL/PGQ, la nouvelle partie 16 de la norme, permet de définir un graphe au-dessus de tables ordinaires et de l'interroger en SQL.

Dans Sakila, actor et film deviennent des sommets, et film_actor l'arête qui les relie :

CREATE PROPERTY GRAPH film_graph
  VERTEX TABLES (actor KEY (actor_id), film KEY (film_id))
  EDGE TABLES (
    film_actor KEY (actor_id, film_id)
      SOURCE KEY (actor_id) REFERENCES actor (actor_id)
      DESTINATION KEY (film_id) REFERENCES film (film_id)
      LABEL acted_in
  );

Remarque : le graphe ne copie pas les données ; il décrit comment les tables existantes sont reliées.

L'opérateur GRAPH_TABLE trouve des chemins selon un motif. Cette requête renvoie les acteurs qui ont joué dans un film avec Penelope Guiness :

SELECT DISTINCT partner
FROM GRAPH_TABLE (film_graph
  MATCH (a IS actor) -[IS acted_in]-> (f IS film) <-[IS acted_in]- (b IS actor)
  WHERE a.first_name = 'PENELOPE'
    AND a.last_name = 'GUINESS'
    AND b.actor_id <> a.actor_id
  COLUMNS (b.first_name || ' ' || b.last_name AS partner)
);

Résultat : une ligne par partenaire de tournage. Le motif se lit comme le dessin : acteur → film ← acteur.

Le même résultat s'obtient avec deux jointures de film_actor, que vous verrez dans le module sur les jointures. Pour des chemins plus longs, comme « acteurs reliés par deux films », la syntaxe de graphe est bien plus courte. Aujourd'hui, SQL/PGQ est pris en charge par Oracle Database 23ai ; la prise en charge dans PostgreSQL est en cours de développement.

Les dialectes SQL : en quoi les bases s'écartent de la norme

Un dialecte SQL est la version de SQL implémentée par une base de données donnée : les fonctionnalités de la norme qu'elle prend en charge, plus ses propres extensions. Les requêtes simples se ressemblent partout, mais les détails varient. Par exemple, les cinq films les plus longs selon la base :

-- Norme (PostgreSQL, Oracle)
SELECT title, length
FROM film
ORDER BY length DESC
FETCH FIRST 5 ROWS ONLY;

-- MySQL, MariaDB, SQLite, PostgreSQL
SELECT title, length
FROM film
ORDER BY length DESC
LIMIT 5;

-- SQL Server
SELECT TOP 5 title, length
FROM film
ORDER BY length DESC;

Résultat : les mêmes cinq films dans tous les cas. LIMIT et TOP sont apparus avant le FETCH FIRST normalisé et restent plus répandus.

Autres différences fréquentes :

PostgreSQL est généralement considéré comme le plus proche de la norme. MySQL s'en écarte le plus, même si ses versions récentes ont ajouté les CTE, les fonctions de fenêtrage et d'autres fonctionnalités normalisées.

Comment écrire du SQL portable

Porter un schéma vers une autre base demande toujours un peu de travail, mais quelques habitudes gardent les requêtes proches de la norme :

• Préférez les constructions normalisées quand la base les prend en charge : CASE plutôt que IF(), COALESCE plutôt que IFNULL ou ISNULL, JOIN ... ON explicite.
• Utilisez CAST(x AS type) plutôt que des raccourcis comme x::type de PostgreSQL.
• Évitez les noms entre délimiteurs : des noms en minuscules et sans espaces n'en ont besoin dans aucune base.
• Regroupez les parties propres à une base, comme la limite de lignes ou les fonctions de date, à des endroits bien identifiés.

Sur ce site, les mêmes exercices peuvent être résolus sur plusieurs bases : vous verrez ces différences en pratique. Le module suivant commence à écrire des requêtes avec SELECT, l'instruction derrière toute lecture de données.

Points clés :

• La norme SQL est l'ISO/IEC 9075 ; elle a commencé avec SQL-86, et la version actuelle est SQL:2023.
• SQL-92 a fixé la base commune, SQL:1999 et SQL:2003 ont ajouté les CTE et les fonctions de fenêtrage, SQL:2016 les fonctions JSON.
• SQL:2023 ajoute le type JSON et les requêtes sur graphes de propriétés (SQL/PGQ) au-dessus de tables ordinaires.
• Un dialecte SQL, c'est la norme telle qu'une base l'implémente, plus ses extensions.
• Les requêtes de base sont portables ; la limite de lignes, les fonctions de chaînes, l'auto-incrément et les délimiteurs varient le plus.

Questions fréquentes

Quelle est la dernière version de la norme SQL ?

La dernière version est SQL:2023 (ISO/IEC 9075:2023), publiée en juin 2023. Elle a ajouté le type de données JSON, les requêtes sur graphes de propriétés (SQL/PGQ) et plusieurs fonctionnalités plus petites, comme GREATEST, LEAST et ANY_VALUE.

Quelle est la différence entre ANSI SQL et ISO SQL ?

Aujourd'hui, c'est la même norme. L'ANSI a publié la première version en 1986, l'ISO l'a adoptée en 1987, et depuis l'ANSI reprend la norme ISO/IEC 9075. « ANSI SQL » est simplement le nom courant du SQL normalisé.

Une base de données prend-elle en charge toute la norme SQL ?

Non. Chaque base prend en charge Core SQL et un ensemble différent de fonctionnalités facultatives, et ajoute ses propres extensions. PostgreSQL est généralement considéré comme le plus proche de la norme.

Faut-il encore apprendre SQL-92 ?

La syntaxe de SQL-92 est la base qui fonctionne dans presque toutes les bases de données : c'est un bon point de départ. Mais le SQL moderne comprend aussi les CTE, les fonctions de fenêtrage et le JSON, que le travail analytique utilise au quotidien.

Questions d'entretien

Qu'est-ce qu'un dialecte SQL ?

Un dialecte SQL est la version de SQL implémentée par une base donnée : une partie de la norme ISO plus les extensions de l'éditeur. Exemples : T-SQL dans SQL Server et les dialectes SQL d'Oracle, MySQL et PostgreSQL. La syntaxe de base est commune ; les détails comme la limite de lignes, les fonctions et les types de données varient.

Citez quelques différences de syntaxe entre MySQL et SQL Server.

MySQL limite les lignes avec LIMIT, SQL Server avec TOP ou OFFSET ... FETCH. MySQL concatène les chaînes avec CONCAT, SQL Server aussi avec + ; MySQL délimite les noms par des accents graves, SQL Server par des crochets. Les clés auto-incrémentées s'écrivent AUTO_INCREMENT dans MySQL et IDENTITY dans SQL Server.

Qu'a ajouté SQL:2023 à la norme ?

Un type de données JSON natif et SQL/PGQ, des requêtes sur graphes de propriétés au-dessus de tables relationnelles avec CREATE PROPERTY GRAPH et GRAPH_TABLE. Il a aussi ajouté des fonctionnalités plus petites comme GREATEST, LEAST et ANY_VALUE.

Comment rendre une requête SQL portable entre bases de données ?

En utilisant des constructions normalisées : JOIN ... ON explicite, CASE, COALESCE, CAST. Il faut éviter les fonctions propres à un éditeur et les identifiants entre délimiteurs, et isoler les parties qui doivent différer, comme la limite de lignes et les fonctions de date.