20
Chapitre 20 sur 21

Bonnes pratiques SQL

Vous savez déjà écrire des requêtes (SELECT, WHERE, JOIN, GROUP BY…). Maintenant, on passe en mode professionnel : rendre vos requêtes lisibles, sûres (moins de risques d’erreurs), et performantes (rapides quand la base grandit).

Appliquer les bons réflexes

Une requête qui “marche” n’est pas forcément une bonne requête

Une requête peut fonctionner et pourtant être difficile à relire, risquée (UPDATE/DELETE sans garde-fou), ou lente sur une base réelle. Les bonnes pratiques vous évitent des bugs et vous font gagner du temps.

🏗️

Analogie : chantier

Construire vite, c’est bien. Construire solide, c’est mieux. En SQL, les bonnes pratiques sont les “normes de sécurité” : elles évitent l’effondrement.

1) Lisibilité : écrire des requêtes faciles à relire

Quand une requête fait 10 lignes, vous devez pouvoir la comprendre en 10 secondes. Cela passe par : indentation, retours à la ligne, alias clairs.

-- Moins lisible
SELECT * FROM commandes JOIN clients ON commandes.client_id=clients.id WHERE date_commande > '2024-01-01' ORDER BY date_commande DESC;

-- Lisible (version pro)
SELECT
  co.id,
  co.date_commande,
  c.nom
FROM commandes co
JOIN clients c ON co.client_id = c.id
WHERE co.date_commande > '2024-01-01'
ORDER BY co.date_commande DESC;
✅

Réflexe

Utilisez des alias courts et cohérents : clients c, commandes co, produits p…

2) Éviter SELECT * (sauf au début)

SELECT * est pratique quand on explore une table, mais en production il pose souvent problème : vous récupérez trop de colonnes, et vos résultats deviennent confus avec les JOIN.

✅

Quand c’est OK

Explorer rapidement une table en apprentissage.

⚠️

Quand éviter

JOIN, API, pages web, exports, statistiques.

🎯

Bonne pratique

Sélectionner uniquement les colonnes utiles.

🚀

Avantage

Plus rapide et plus lisible.

3) Sécurité : UPDATE / DELETE = toujours une vérification

Les requêtes de modification sont puissantes. Un oubli de WHERE peut impacter toutes les lignes. En entreprise, c’est un incident.

⚠️

Règle d’or

Avant un UPDATE ou un DELETE, faites d’abord un SELECT avec exactement le même WHERE, pour vérifier quelles lignes seront touchées.

-- Étape 1 : vérifier (SELECT)
SELECT id, titre, note
FROM films
WHERE id = 3;

-- Étape 2 : modifier (UPDATE) quand vous êtes sûr
UPDATE films
SET note = 10
WHERE id = 3;

4) Modélisation : clés primaires et étrangères partout où c’est logique

Sans clés, vous perdez la cohérence : doublons, liens cassés, UPDATE imprécis. Les clés primaires/étrangères structurent votre base et rendent vos JOIN fiables.

🧠

Raccourci mental

Table “parent” = PK (id).
Table “enfant” = FK (parent_id) vers la PK.

5) Performance : indexer les colonnes utilisées dans WHERE / JOIN / ORDER BY

Un index est une structure qui accélère les recherches. Sans index, la base peut parcourir toute la table (lent quand il y a beaucoup de lignes).

-- Exemple : accélérer les recherches par nom
CREATE INDEX idx_clients_nom ON clients(nom);
⚠️

Attention

Les index accélèrent la lecture, mais peuvent ralentir un peu les INSERT/UPDATE/DELETE (car l’index doit être mis à jour). On indexe “intelligemment”, pas partout.

6) Transactions : regrouper des actions qui doivent réussir ensemble

Une transaction permet de faire plusieurs opérations comme un bloc : soit tout réussit, soit on annule tout. C’est essentiel pour éviter une base incohérente.

-- Exemple conceptuel (selon SGBD)
BEGIN;
UPDATE comptes SET solde = solde - 50 WHERE id = 1;
UPDATE comptes SET solde = solde + 50 WHERE id = 2;
COMMIT;
✅

Idée simple

Si vous “déplacez” de l’argent, vous ne voulez jamais débiter sans créditer (ou l’inverse). La transaction garantit ce comportement.

7) Données propres : contraintes et validations

Même si vous validez côté application (PHP/JS), la base doit aussi protéger la cohérence : NOT NULL, UNIQUE, CHECK (selon SGBD).

-- Exemple : email unique + obligatoire
CREATE TABLE utilisateurs (
  id INTEGER PRIMARY KEY,
  email TEXT NOT NULL UNIQUE
);

Checklist rapide avant d’envoyer une requête “en prod”

🧾

Lisibilité

Indentation, alias, colonnes explicites (pas SELECT *).

🛡️

Sécurité

UPDATE/DELETE : SELECT de contrôle + WHERE précis.

🔗

Cohérence

PK/FK, contraintes (NOT NULL, UNIQUE) si nécessaire.

🚀

Performance

Index sur les colonnes clés (WHERE/JOIN/ORDER BY).

Exercice pratique : passer une requête en “version pro”

Prenez une requête “rapide” (souvent avec SELECT * et pas de mise en forme), puis transformez-la en version lisible et sûre.

-- Point de départ (à améliorer)
SELECT * FROM commandes JOIN clients ON commandes.client_id = clients.id WHERE date_commande > '2024-01-01';
🎯

Consignes

  • Remplacer * par 3 ou 4 colonnes utiles
  • Ajouter des alias (co, c)
  • Mettre la requête en forme (retours à la ligne)
  • Ajouter un ORDER BY cohérent

Récapitulatif du chapitre

✅

Ce que vous devez retenir

  • Une requête doit être lisible (alias, indentation, colonnes explicites)
  • UPDATE/DELETE : toujours une vérification et un WHERE précis
  • PK/FK + contraintes = données cohérentes
  • Index = performances sur les colonnes stratégiques
  • Transactions = sécurité pour les opérations multiples

Prochain chapitre : un mini-projet final guidé pour réutiliser tout ce que vous avez appris.

Chapitre 19 : Gestion des erreurs courantes Chapitre 21 : Mini-projet final guidé