Builders Academy
Bases de Données — Choisir et Optimiser
1 of 2

Chapitre 1 · Leçon 1

SQL vs NoSQL

Choisir la base de données adaptée au problème

Section 1

Critères de choix

Step 1

La matrice de décision

Le choix d'une base de données dépend de la structure des données, des patterns d'accès, des besoins en cohérence et du volume. Il n'y a pas une seule bonne réponse — les meilleurs systèmes utilisent souvent plusieurs types.

snippet.typescript

typescript
1/*
2 * Guide de sélection de base de données
3 *
4 * ══════════════════════════════════════════════════════════════════
5 * PostgreSQL (SQL relationnel)
6 * ══════════════════════════════════════════════════════════════════
7 * ✅ Données structurées avec relations (users, tutorials, chapters)
8 * ✅ Transactions ACID obligatoires (paiements, commandes)
9 * ✅ Requêtes complexes (JOINs, agrégations, fenêtres)
10 * ✅ Cohérence forte requise
11 * ✅ Schéma stable et bien défini
12 * ❌ Schema flexible difficile
13 * ❌ Scaling horizontal complexe
14 * 📦 Usher Platform : users, tutorials, chapters, lessons, progress
15 *
16 *
17 * ══════════════════════════════════════════════════════════════════
18 * MongoDB (NoSQL document)
19 * ══════════════════════════════════════════════════════════════════
20 * ✅ Données semi-structurées, schéma flexible
21 * ✅ Documents imbriqués (évite les JOINs coûteux)
22 * ✅ Développement rapide, schéma évolutif
23 * ✅ Scaling horizontal natif (sharding)
24 * ❌ Transactions inter-documents complexes
25 * ❌ Cohérence éventuelle par défaut
26 * 📦 Logs d'activité, profils avec champs variables, CMS
27 *
28 *
29 * ══════════════════════════════════════════════════════════════════
30 * Redis (Key-Value in-memory)
31 * ══════════════════════════════════════════════════════════════════
32 * ✅ Cache (réponses API, résultats de requêtes)
33 * ✅ Sessions et tokens
34 * ✅ Rate limiting (INCR + EXPIRE)
35 * ✅ Leaderboards (ZADD, ZRANGE)
36 * ✅ Pub/Sub pour événements temps réel
37 * ✅ Queues légères (LIST LPUSH/BRPOP)
38 * ❌ Pas une base de données principale (données en RAM = coûteux)
39 * 📦 Usher Platform : sessions, cache API, rate limiting, progress cache
40 *
41 *
42 * ══════════════════════════════════════════════════════════════════
43 * Elasticsearch (Search engine)
44 * ══════════════════════════════════════════════════════════════════
45 * ✅ Recherche full-text ultra-rapide
46 * ✅ Analyse de logs (ELK Stack)
47 * ✅ Recherche facettée (filtres combinés)
48 * ✅ Autocomplétion
49 * ❌ Pas une source de vérité (synchroniser depuis PostgreSQL)
50 * ❌ Cohérence éventuelle
51 * 📦 Usher Platform : recherche de tutoriels, autocomplétion
52 */

Step 2

Architecture polyglotte — Usher Platform

En pratique, un système moderne utilise plusieurs bases de données, chacune optimisée pour son cas d'usage. C'est la persistence polyglotte.

snippet.typescript

typescript
1/*
2 * Guide de sélection de base de données
3 *
4 * ══════════════════════════════════════════════════════════════════
5 * PostgreSQL (SQL relationnel)
6 * ══════════════════════════════════════════════════════════════════
7 * ✅ Données structurées avec relations (users, tutorials, chapters)
8 * ✅ Transactions ACID obligatoires (paiements, commandes)
9 * ✅ Requêtes complexes (JOINs, agrégations, fenêtres)
10 * ✅ Cohérence forte requise
11 * ✅ Schéma stable et bien défini
12 * ❌ Schema flexible difficile
13 * ❌ Scaling horizontal complexe
14 * 📦 Usher Platform : users, tutorials, chapters, lessons, progress
15 *
16 *
17 * ══════════════════════════════════════════════════════════════════
18 * MongoDB (NoSQL document)
19 * ══════════════════════════════════════════════════════════════════
20 * ✅ Données semi-structurées, schéma flexible
21 * ✅ Documents imbriqués (évite les JOINs coûteux)
22 * ✅ Développement rapide, schéma évolutif
23 * ✅ Scaling horizontal natif (sharding)
24 * ❌ Transactions inter-documents complexes
25 * ❌ Cohérence éventuelle par défaut
26 * 📦 Logs d'activité, profils avec champs variables, CMS
27 *
28 *
29 * ══════════════════════════════════════════════════════════════════
30 * Redis (Key-Value in-memory)
31 * ══════════════════════════════════════════════════════════════════
32 * ✅ Cache (réponses API, résultats de requêtes)
33 * ✅ Sessions et tokens
34 * ✅ Rate limiting (INCR + EXPIRE)
35 * ✅ Leaderboards (ZADD, ZRANGE)
36 * ✅ Pub/Sub pour événements temps réel
37 * ✅ Queues légères (LIST LPUSH/BRPOP)
38 * ❌ Pas une base de données principale (données en RAM = coûteux)
39 * 📦 Usher Platform : sessions, cache API, rate limiting, progress cache
40 *
41 *
42 * ══════════════════════════════════════════════════════════════════
43 * Elasticsearch (Search engine)
44 * ══════════════════════════════════════════════════════════════════
45 * ✅ Recherche full-text ultra-rapide
46 * ✅ Analyse de logs (ELK Stack)
47 * ✅ Recherche facettée (filtres combinés)
48 * ✅ Autocomplétion
49 * ❌ Pas une source de vérité (synchroniser depuis PostgreSQL)
50 * ❌ Cohérence éventuelle
51 * 📦 Usher Platform : recherche de tutoriels, autocomplétion
52 */

Topics and skills covered

  • System Design
  • PostgreSQL
  • MongoDB
  • Redis
  • NoSQL