- Formateur & Validateur SQL en ligne

Pourquoi formater et valider le SQL

Pour qui : Développeurs back-end, DBA, data analysts, DevOps, développeurs full-stack travaillant avec MySQL, PostgreSQL, SQLite, MariaDB ou tout autre SGBDR.

Une requête SQL peut être correcte fonctionnellement mais rester illisible et difficile à maintenir si elle n'est pas formatée. Les problèmes courants rencontrés quotidiennement :

• ❌ Requêtes minifiées illisibles — Une requête sur une seule ligne de 500 caractères est impossible à déboguer
• ❌ Indentation incohérente — Chaque développeur de l'équipe utilise un style différent, rendant les revues de code difficiles
• ❌ Erreurs de syntaxe masquées — Une virgule manquante ou une parenthèse non fermée dans une longue requête est quasi invisible
• ❌ Mots-clés en minuscules — Mélanger select, SELECT, Select nuit à la lisibilité
• ❌ Revues de code pénibles — Comparer deux versions de requêtes non formatées dans un diff Git est fastidieux

Solution : Un formateur SQL standardise automatiquement le style, détecte les erreurs de syntaxe courantes et produit un SQL prêt pour la production ou la revue de code.

Comment utiliser ce formateur SQL

L'outil fonctionne entièrement dans votre navigateur — aucune donnée n'est envoyée à un serveur. Voici le workflow en 5 étapes :

1. Choisir le dialecte — MySQL, PostgreSQL, SQLite ou SQL Standard selon votre SGBD
2. Coller votre requête — Dans la zone "Entrée SQL" (raccourcis Ctrl+V / Cmd+V)
3. Cliquer ✨ Formater — Aère et indente la requête avec coloration syntaxique
4. Ou cliquer 🔍 Valider — Vérifie la syntaxe et liste les erreurs détectées
5. 📋 Copier le résultat — Récupère la requête formatée en un clic

Fonctionnalités disponibles :

Exemple — avant/après le formatage :

-- ❌ Avant (illisible)
SELECT u.id,u.nom,u.email,COUNT(c.id) AS nb FROM utilisateurs u INNER JOIN commandes c ON u.id=c.user_id WHERE u.statut='actif' AND c.montant>100 GROUP BY u.id ORDER BY nb DESC LIMIT 20

-- ✅ Après ✨ Formater
SELECT u.id, u.nom, u.email, COUNT(c.id) AS nb
FROM utilisateurs u
INNER JOIN commandes c ON u.id = c.user_id
WHERE u.statut = 'actif'
    AND c.montant > 100
GROUP BY u.id
ORDER BY nb DESC
LIMIT 20

Syntaxe SQL — les règles essentielles

SQL est un langage déclaratif standardisé (ISO/IEC 9075) mais chaque SGBD y ajoute ses extensions. Voici les règles fondamentales communes à tous les dialectes :

Structure d'une requête SELECT

Une requête SELECT respecte un ordre précis de clauses :

SELECT   [DISTINCT] colonnes          -- 1. Quoi sélectionner
FROM     tables                        -- 2. D'où
[JOIN    table ON condition]           -- 3. Jointures (optionnel)
[WHERE   condition]                    -- 4. Filtrage des lignes
[GROUP BY colonnes]                    -- 5. Agrégation
[HAVING  condition_agregat]            -- 6. Filtrage des groupes
[ORDER BY colonnes [ASC|DESC]]         -- 7. Tri
[LIMIT   n OFFSET m]                   -- 8. Pagination

Types de jointures SQL

Agrégations et fonctions essentielles

-- Fonctions d'agrégation courantes
SELECT
    COUNT(*)          AS total_lignes,
    COUNT(DISTINCT id) AS valeurs_uniques,
    SUM(montant)      AS total,
    AVG(montant)      AS moyenne,
    MIN(date_creation) AS premiere_date,
    MAX(montant)      AS montant_max
FROM commandes
WHERE statut = 'validee';

-- Fonctions de fenêtrage (SQL avancé)
SELECT
    nom,
    salaire,
    ROW_NUMBER() OVER (PARTITION BY departement ORDER BY salaire DESC) AS rang
FROM employes;

DML — Manipulation de données

-- INSERT : Insérer des données
INSERT INTO produits (nom, prix, stock)
VALUES ('Clavier', 49.99, 200);

-- INSERT multiple (une seule requête)
INSERT INTO produits (nom, prix, stock)
VALUES
    ('Souris', 29.99, 150),
    ('Écran', 299.99, 30),
    ('Hub USB', 19.99, 500);

-- UPDATE : Modifier des données
UPDATE produits
SET prix = 39.99, stock = 180
WHERE id = 1;

-- DELETE : Supprimer des données
DELETE FROM produits
WHERE stock = 0
    AND date_creation < '2023-01-01';

Erreurs SQL fréquentes et solutions

Voici les erreurs de syntaxe les plus courantes rencontrées par les développeurs, avec leurs corrections :

Erreurs de syntaxe classiques

Erreurs logiques fréquentes

-- ❌ DELETE sans WHERE (supprime tout !)
DELETE FROM sessions;

-- ✅ Toujours spécifier une condition
DELETE FROM sessions
WHERE expire_at < NOW();

-- ❌ UPDATE sans WHERE (met à jour toutes les lignes !)
UPDATE users SET is_admin = 1;

-- ✅ Cibler précisément
UPDATE users
SET is_admin = 1
WHERE email = 'admin@example.com';

-- ❌ Utiliser = au lieu de IS pour NULL
SELECT * FROM users WHERE deleted_at = NULL;  -- renvoie 0 résultats !

-- ✅ IS NULL / IS NOT NULL
SELECT * FROM users WHERE deleted_at IS NULL;

Pièges des sous-requêtes

-- ❌ Sous-requête qui retourne plusieurs lignes avec =
SELECT * FROM users
WHERE id = (SELECT id FROM admins);  -- erreur si plusieurs admins

-- ✅ Utiliser IN pour une liste de valeurs
SELECT * FROM users
WHERE id IN (SELECT id FROM admins);

-- ✅ Ou EXISTS pour vérifier l'existence
SELECT * FROM users u
WHERE EXISTS (
    SELECT 1 FROM admins a WHERE a.user_id = u.id
);

SQL selon les SGBD (MySQL, PostgreSQL, SQLite)

Chaque système de gestion de base de données ajoute ses extensions propriétaires à la norme SQL. Voici les différences essentielles à connaître :

MySQL / MariaDB — Particularités

-- AUTO_INCREMENT (MySQL) vs SERIAL (PostgreSQL) vs AUTOINCREMENT (SQLite)
CREATE TABLE articles (
    id INT AUTO_INCREMENT PRIMARY KEY,  -- MySQL/MariaDB
    titre VARCHAR(255) NOT NULL,
    contenu TEXT,
    cree_le TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    mis_a_jour TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- Pagination MySQL
SELECT * FROM articles ORDER BY id DESC LIMIT 10 OFFSET 20;

-- UPSERT MySQL (INSERT OR UPDATE)
INSERT INTO config (cle, valeur)
VALUES ('theme', 'dark')
ON DUPLICATE KEY UPDATE valeur = 'dark';

PostgreSQL — Fonctionnalités avancées

-- Types natifs PostgreSQL
CREATE TABLE events (
    id SERIAL PRIMARY KEY,           -- auto-incrémenté
    payload JSON NOT NULL,           -- ou JSONB pour indexation
    tags TEXT[],                     -- tableau natif
    cree_le TIMESTAMPTZ DEFAULT NOW()
);

-- CTE (Common Table Expression) — plus lisible que les sous-requêtes
WITH ventes_mensuelles AS (
    SELECT
        DATE_TRUNC('month', date_vente) AS mois,
        SUM(montant) AS total
    FROM ventes
    GROUP BY mois
)
SELECT mois, total
FROM ventes_mensuelles
WHERE total > 10000
ORDER BY mois;

-- UPSERT PostgreSQL
INSERT INTO config (cle, valeur)
VALUES ('theme', 'dark')
ON CONFLICT (cle) DO UPDATE SET valeur = EXCLUDED.valeur;

-- Full-text search natif
SELECT titre, ts_rank(to_tsvector(contenu), query) AS score
FROM articles, plainto_tsquery('français sql') query
WHERE to_tsvector(contenu) @@ query
ORDER BY score DESC;

SQLite — Légèreté et simplicité

-- SQLite : typage flexible (affinités de types)
CREATE TABLE notes (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    titre TEXT NOT NULL,
    contenu TEXT,
    importance REAL DEFAULT 0,
    cree_le TEXT DEFAULT (datetime('now'))
);

-- UPSERT SQLite (3.24+)
INSERT INTO config (cle, valeur)
VALUES ('theme', 'dark')
ON CONFLICT(cle) DO UPDATE SET valeur = excluded.valeur;

-- Pragma SQLite pour les clés étrangères (désactivées par défaut !)
PRAGMA foreign_keys = ON;

Bonnes pratiques pour un SQL lisible

Adopter un style cohérent améliore la maintenabilité, facilite les revues de code et réduit les bugs. Voici les conventions recommandées :

Conventions de nommage

-- ✅ Nommage recommandé (snake_case, pluriel pour les tables)
CREATE TABLE utilisateurs (
    id            INT AUTO_INCREMENT PRIMARY KEY,
    nom_complet   VARCHAR(100) NOT NULL,
    email         VARCHAR(255) UNIQUE NOT NULL,
    est_actif     BOOLEAN DEFAULT TRUE,
    cree_le       TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    modifie_le    TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

-- ❌ À éviter : noms ambigus, CamelCase, abréviations excessives
CREATE TABLE Usr (UsrNm VARCHAR(100), Eml VARCHAR(255));

Aliasing et lisibilité

-- ✅ Alias explicites et mots-clés AS toujours présents
SELECT
    u.id                            AS user_id,
    CONCAT(u.prenom, ' ', u.nom)   AS nom_complet,
    COUNT(c.id)                    AS nb_commandes,
    SUM(c.montant)                 AS chiffre_affaires
FROM utilisateurs AS u
LEFT JOIN commandes AS c ON c.user_id = u.id
WHERE u.est_actif = TRUE
GROUP BY u.id, u.prenom, u.nom
ORDER BY chiffre_affaires DESC;

Performances — Règles clés

• ✅ Sélectionnez uniquement les colonnes nécessaires — Évitez SELECT * en production
• ✅ Indexez les colonnes de jointure et de filtre — WHERE, JOIN ON, ORDER BY
• ✅ Utilisez EXPLAIN pour analyser le plan d'exécution avant déploiement
• ✅ Évitez les fonctions sur les colonnes indexées dans WHERE — WHERE YEAR(date_creation) = 2024 n'utilise pas l'index
• ✅ Préférez les requêtes préparées contre les injections SQL et pour la performance (cache du plan)

-- ❌ Mauvais : fonction sur colonne indexée (full scan)
SELECT * FROM commandes
WHERE YEAR(date_creation) = 2024;

-- ✅ Bon : range sur la colonne indexée
SELECT * FROM commandes
WHERE date_creation >= '2024-01-01'
    AND date_creation < '2025-01-01';

-- ✅ EXPLAIN pour analyser
EXPLAIN SELECT u.id, COUNT(c.id)
FROM utilisateurs u
INNER JOIN commandes c ON u.id = c.user_id
GROUP BY u.id;

Transactions et intégrité des données

-- ✅ Toujours utiliser des transactions pour les opérations critiques
BEGIN;

UPDATE comptes SET solde = solde - 500 WHERE id = 1;
UPDATE comptes SET solde = solde + 500 WHERE id = 2;

-- Vérification avant validation
SELECT solde FROM comptes WHERE id = 1;  -- doit être >= 0

COMMIT;  -- ou ROLLBACK en cas d'erreur

FAQ — Questions fréquentes

Est-ce que mes requêtes SQL sont envoyées à un serveur ?

Non. Cet outil fonctionne entièrement dans votre navigateur avec JavaScript. Aucune requête SQL, aucune donnée n'est transmise à un serveur externe. Vous pouvez l'utiliser en toute sécurité avec des requêtes contenant des données sensibles.

Quels dialectes SQL sont supportés ?

Le formateur supporte la syntaxe SQL standard et les extensions des 4 dialectes les plus populaires : MySQL/MariaDB, PostgreSQL, SQLite et SQL Standard ISO. Les mots-clés spécifiques à chaque dialecte sont reconnus et mis en surbrillance.

Pourquoi utiliser un formateur plutôt que l'IDE ?

Un formateur en ligne est utile quand vous travaillez avec une requête en dehors de votre IDE : dans une interface web, un terminal, une documentation, ou lors d'un partage rapide avec un collègue. Il n'exige aucune installation et fonctionne depuis n'importe quel appareil.

Le validateur détecte-t-il toutes les erreurs SQL ?

Le validateur de cet outil effectue des vérifications syntaxiques côté client (parenthèses, guillemets, virgules parasites, mots-clés manquants). Il ne remplace pas l'exécution réelle sur votre SGBD, qui seul peut détecter les erreurs sémantiques (tables inexistantes, types incompatibles, permissions manquantes).

Comment minifier une requête SQL et à quoi ça sert ?

La minification supprime les commentaires, les indentations et les espaces superflus pour produire une requête sur une seule ligne. Utile pour réduire la taille des requêtes dans des logs, des configurations ou des payloads JSON, ou pour comparer deux requêtes ligne à ligne.

Puis-je formater plusieurs requêtes à la fois ?

Oui. Collez plusieurs requêtes SQL séparées par des points-virgules dans la zone d'entrée. Le formateur traitera l'ensemble du bloc et produira chaque requête formatée dans l'ordre.

Quelle est la différence entre WHERE et HAVING ?

WHERE filtre les lignes individuelles avant l'agrégation. HAVING filtre les groupes après agrégation. Exemple : WHERE montant > 100 exclut les lignes à moins de 100€ ; HAVING SUM(montant) > 1000 exclut les groupes dont la somme est inférieure à 1000€.

Comment éviter les injections SQL ?

Utilisez systématiquement des requêtes préparées (prepared statements) avec des paramètres liés (? ou :nom) plutôt que de concaténer des valeurs utilisateur dans vos requêtes. Exemple en PHP :

// ❌ DANGER : injection SQL possible
$query = "SELECT * FROM users WHERE email = '" . $_POST['email'] . "'";

// ✅ Sécurisé : requête préparée PDO
$stmt = $pdo->prepare("SELECT * FROM users WHERE email = :email");
$stmt->execute([':email' => $_POST['email']]);