00 - Pourquoi comprendre SQL meme avec un ORM
Ce que tu vas apprendre
- Pourquoi les ORM ne suffisent pas pour un dev backend serieux
- Ce que les ORM cachent (et pourquoi ca pose problème)
- Pourquoi PostgreSQL et ce que cette serie couvre
Prerequisites
Avoir deja utilise un ORM (Prisma, Drizzle, TypeORM, Sequelize). Pas besoin de connaître SQL en détail, c'est tout l'objet de cette serie.
47 requêtes pour une page
L'annee dernière, un junior en alternance m'a montre son ecran. Son dashboard Prisma fonctionnait, les donnees s'affichaient, tout semblait normal. Sauf que la page mettait 4 secondes a charger. J'ai active le logging des requêtes SQL dans Prisma (log: ['query'] dans le client) et on a regarde la console.
47 requêtes SQL. Pour une seule page qui affichait une liste de commandes avec leurs produits.
Le code Prisma etait propre. Il faisait un findMany sur les commandes, puis dans la boucle d'affichage React, chaque composant OrderCard faisait un appel API qui declenchait un findUnique pour récupérer les produits de cette commande. Le fameux problème N+1, que je couvre en détail dans l'article 11.
Le fix a pris 2 minutes : un include: { items: true } dans le findMany initial. Mais le junior ne savait pas que c'etait un problème parce qu'il ne savait pas ce que Prisma generait comme SQL derrière. Il n'avait jamais vu un JOIN.
Les ORM, c'est bien. Mais.
Je ne suis pas un anti-ORM. J'utilise Prisma et Drizzle au quotidien. La productivité est réelle : autocompletion TypeScript, migrations automatiques, typage des résultats. Sur paltemps.fr et sur les projets clients, on démarré quasiment toujours avec un ORM.
Le problème, c'est quand l'ORM devient une boîte noire. Tu ecris prisma.user.findMany({ where: { posts: { some: { published: true } } } }) et tu ne sais pas si ca généré un JOIN, un EXISTS, une sous-requête correlee, ou trois requêtes separees. Et quand les performances se degradent, tu ne sais pas ou chercher.
Il y a aussi les cas ou l'ORM ne suffit pas. Les requêtes recursives (hierarchies de categories, arbres de commentaires). Les aggregations complexes avec FILTER, ROLLUP, des window functions. Les migrations zero-downtime sur des tables de millions de lignes. Le tuning de PostgreSQL pour la production. Tout ca, c'est du SQL brut et de la config PostgreSQL.
Pourquoi PostgreSQL
Mon avis est tranche la-dessus : PostgreSQL est le meilleur SGBD relationnel open source. Ca fait 35 ans qu'il existe, il gere le JSON (JSONB), le full-text search, les types geometriques, les index partiels, le Row Level Security, les requêtes recursives, et il a un ecosysteme d'extensions énorme (PostGIS, pg_trgm, timescaledb).
MySQL a ses qualités, mais PostgreSQL est plus rigoureux sur le respect du standard SQL, plus riche en fonctionnalités, et la communauté est excellente. Selon le classement DB-Engines, PostgreSQL est le SGBD qui progresse le plus depuis 10 ans.
Si tu fais du backend en TypeScript, tu as probablement deja PostgreSQL en prod (ou tu devrais).
Ce que couvre cette serie
| # | Article | Contenu |
|---|---|---|
| 01 | SELECT fondamentaux | WHERE, ORDER BY, LIMIT, CASE WHEN, pièges |
| 02 | Les JOINs | INNER, LEFT, RIGHT, FULL, CROSS, self JOIN |
| 03 | Aggregation | GROUP BY, HAVING, COUNT, SUM, FILTER, ROLLUP |
| 04 | Sous-requêtes et CTEs | WITH, WITH RECURSIVE, sous-requêtes correlees |
| 05 | Les index | B-tree, GIN, GiST, partial, EXPLAIN ANALYZE |
| 06 | Transactions et ACID | BEGIN, COMMIT, isolation levels, deadlocks |
| 07 | Fonctions PL/pgSQL | Functions, procedures, exceptions |
| 08 | Triggers | Audit, timestamps, validation automatique |
| 09 | Vues materialisees | Vues, REFRESH CONCURRENTLY, generated columns |
| 10 | JSON et JSONB | Operateurs, GIN index, quand utiliser |
| 11 | Le problème N+1 | Détection, correction, DataLoader |
| 12 | Migrations | Versionning, zero-downtime, outils |
| 13 | Performance | EXPLAIN ANALYZE, PgBouncer, tuning |
| 14 | Sécurité | Rôles, RLS, pg_hba.conf, injection SQL |
| 15 | Glossaire | Tous les termes de la serie |
Chaque article est un atelier. On créé des tables, on inséré des donnees, on exécuté des requêtes, on regarde les résultats. C'est du SQL que tu peux copier-coller dans un psql ou un DBeaver et exécuter directement.
Si tu viens de la serie Architecture hexagonale, tu verras comment le pattern Repository encapsule justement ces requêtes SQL. Et si tu fais de la serie Tests fondamentaux, tu comprendras mieux les tests d'intégration avec une vraie base de donnees.
Résumé
- Les ORM sont utiles mais cachent le SQL généré, ce qui rend le debug et l'optimisation difficiles
- Comprendre SQL, c'est pouvoir lire un EXPLAIN ANALYZE, écrire une CTE recursive et faire une migration zero-downtime
- PostgreSQL est le SGBD open source le plus complet et le plus fiable
- Cette serie couvre tout ce qu'un dev backend doit savoir, des fondamentaux SELECT aux optimisations de production
Article suivant : 01 - SELECT, WHERE, ORDER BY : les fondamentaux solides