DisponibleInclus dans l’accès bêta

Micro-formation · Débutant

SQL, PostgreSQL, MySQL et SQL Server : quelles différences ?

Comprendre le langage, les moteurs et les dialectes pour choisir une documentation et écrire du SQL portable avec discernement.

45 à 60 minSQL commun · PostgreSQL · MySQL · SQL Server5 leçons · 6 activités disponibles
Commencer la formation

Accès bêta gratuit pendant 30 jours · aucun paiement · progression enregistrée

Le problème métier

Une personne pense apprendre PostgreSQL alors qu’elle apprend une syntaxe SQL, puis découvre des différences dans un autre outil.

Ce que vous saurez faire

Distinguer langage, base, SGBD, serveur et dialecte, puis reconnaître les différences qui comptent.

  • Nommer les quatre notions sans les confondre
  • Identifier une différence de dialecte
  • Choisir une ressource adaptée au moteur

Limites de cette micro-formation

Cette micro-formation cible une compétence précise. Elle ne remplace pas un parcours complet ni une formation d’administration de serveur.

Prérequis

  • Savoir ce qu’est une table

Projet et pratique

6 exercices vérifiés sont disponibles. La validation repose sur les exercices du programme.

Cours interactif · 5 micro-leçons · 6 validations

Comprendre les moteurs et les dialectes sans les confondre

Partez d’un problème réel, comparez les syntaxes, puis validez chaque décision. Les exemples sont reliés aux documentations officielles.

Progression0 / 6
0/6
01
Séparer le langage, les données et le logiciel7 à 9 min · Expliquer clairement SQL, base de données, SGBD, serveur et dialecte.

Situation métier

Une collègue annonce que « la base SQL est en panne ». Cette phrase ne permet pas de savoir si la donnée, le serveur, la connexion ou une requête pose problème.

Question à résoudre

De quoi parle-t-on exactement lorsque l’on dit simplement SQL ?

SQL est un langage qui exprime une intention : lire, relier, ajouter ou contrôler des données.

Une base de données est l’ensemble organisé des données et de leurs règles.

PostgreSQL, MySQL et SQL Server sont des SGBD : des logiciels qui stockent, protègent et traitent les données.

Un serveur ou une instance fait fonctionner le SGBD. Un dialecte est la manière dont un produit implémente et étend SQL.

Exemple vérifié

Langage et logicielSQL commun · PostgreSQL

SELECT exprime une demande de lecture ; PostgreSQL vérifie les droits, choisit un plan et produit le résultat.

Erreur fréquente Présenter PostgreSQL comme une version de SQL. C’est un SGBD qui utilise SQL et ajoute ses propres capacités.

À retenir SQL décrit l’intention ; le SGBD l’interprète et gère les données.

Quelle phrase distingue correctement SQL et PostgreSQL ?
Sources officielles
02
Commencer par le tronc commun7 à 9 min · Reconnaître une requête de lecture simple largement portable.

Situation métier

Une équipe doit produire le même rapport simple sur PostgreSQL, MySQL et SQL Server.

Question à résoudre

Faut-il écrire trois requêtes entièrement différentes ?

SELECT, FROM, WHERE, GROUP BY, HAVING et ORDER BY forment un socle largement partagé.

La portabilité dépend aussi des types, fonctions, conversions, collations et comportements autour de NULL.

Aucun moteur ne garantit l’ordre des lignes sans ORDER BY.

Une requête portable est une hypothèse testée sur les moteurs et versions ciblés.

Exemple vérifié

Rapport de baseSQL commun
SELECT city, COUNT(*) AS orders
FROM orders
WHERE status = 'paid'
GROUP BY city
ORDER BY orders DESC, city;

La forme est commune, mais les données, types et règles de tri doivent encore être comparables.

Erreur fréquente Croire qu’une requête acceptée par trois moteurs donnera automatiquement le même résultat sur trois configurations.

À retenir Commencez par le socle commun, puis testez les différences utiles.

Quelle affirmation est la plus prudente ?
Sources officielles
03
Reconnaître une différence de dialecte9 à 11 min · Adapter une limitation de lignes sans modifier l’intention métier.

Situation métier

Une requête copiée depuis un guide contient TOP (3) et échoue dans PostgreSQL.

Question à résoudre

L’intention est-elle fausse, ou seulement sa formulation ?

Limiter un résultat est une intention commune, mais les syntaxes historiques diffèrent.

PostgreSQL et MySQL acceptent LIMIT. SQL Server propose TOP et OFFSET … FETCH.

PostgreSQL délimite les identifiants avec des guillemets doubles ; MySQL utilise souvent les accents graves ; SQL Server accepte notamment les crochets.

Des noms de colonnes simples et non réservés réduisent les adaptations.

Exemple vérifié

Trois lignesPostgreSQL · MySQL
SELECT id, amount
FROM orders
ORDER BY amount DESC, id
LIMIT 3;

LIMIT vient après ORDER BY.

Trois lignesSQL Server
SELECT TOP (3) id, amount
FROM orders
ORDER BY amount DESC, id;

TOP appartient à T-SQL ; ORDER BY rend le choix reproductible.

Erreur fréquente Retirer ORDER BY pour faire disparaître une erreur : les trois lignes ne seraient plus choisies selon la règle métier.

À retenir Préservez l’intention et le résultat, pas seulement les mots.

Quelle syntaxe limite classiquement PostgreSQL à trois lignes ?
Pourquoi conserver ORDER BY ?
Sources officielles
04
Choisir la bonne documentation7 à 9 min · Trouver une référence adaptée au produit, à la version et au contexte.

Situation métier

Une solution fonctionne sur MySQL 8.4, mais le projet utilise SQL Server. Le mot SQL dans le titre a masqué la différence.

Question à résoudre

Que vérifier avant de copier une syntaxe ?

Identifiez le SGBD et sa version réelle avant de chercher.

Préférez la documentation officielle et vérifiez sa section d’applicabilité.

Distinguez le standard, l’extension du moteur et le comportement dépendant de la configuration.

Reproduisez l’exemple sur un petit jeu contenant aussi des égalités, NULL et cas limites.

Exemple vérifié

Recherche précisePostgreSQL

« PostgreSQL 18 SELECT LIMIT documentation » est plus fiable que « erreur SQL ».

Erreur fréquente Prendre la date récente d’un article pour une preuve de compatibilité avec son moteur.

À retenir La bonne documentation commence par le bon contexte.

Quelle recherche donne le meilleur contexte ?
Sources officielles
05
Porter une requête sans deviner9 à 11 min · Adapter une requête tout en conservant son contrat métier.

Situation métier

Un rapport doit passer de SQL Server à PostgreSQL sans changer les lignes ni les montants affichés.

Question à résoudre

Que faut-il préserver avant de modifier la syntaxe ?

Écrivez le contrat du résultat : colonnes, grain, filtres, ordre, traitement de NULL et valeurs attendues.

Inventoriez les zones sensibles : dates, chaînes, conversions, JSON, identités, fonctions et procédures.

Adaptez une différence à la fois et rejouez le même test après chaque changement.

Comparez les valeurs et les types utiles, pas seulement l’absence d’erreur.

Exemple vérifié

ContratSQL commun

Retourner exactement trois commandes, triées par montant décroissant puis identifiant croissant.

AdaptationPostgreSQL
SELECT id, amount
FROM orders
ORDER BY amount DESC, id
LIMIT 3;

Le test vérifie les trois lignes et leur ordre.

Erreur fréquente Réécrire toute la requête en une fois et ne plus savoir quel changement a modifié le résultat.

À retenir Un portage réussi conserve le contrat métier sur un jeu de contrôle.

Quel contrôle prouve le mieux qu’un portage est correct ?
Sources officielles

Revenir au catalogue complet