Section 11.2.1 : Bases de données — Concepts fondamentaux
🎯 Objectif pédagogique
Comprendre ce qu'est une base de données, pourquoi elles existent, et les différences entre les types principaux (relationnelles vs NoSQL). Vous serez capable de choisir le bon type de base de données pour un projet donné.
Le problème que localStorage ne résout pas
Marc a un Job Tracker qui fonctionne — mais les données sont dans le navigateur de son PC. S'il change de navigateur, tout disparaît. S'il veut que son collègue y accède aussi ? Impossible. Les bases de données stockent les données côté serveur, de manière fiable, partageable et interrogeable.
Les deux grandes familles
Bases relationnelles (SQL)
Données organisées en tables avec des relations entre elles :
Table: users Table: applications
┌────┬──────────┬───────────┐ ┌────┬─────────┬──────────┬─────────┐
│ id │ name │ email │ │ id │ user_id │ company │ status │
├────┼──────────┼───────────┤ ├────┼─────────┼──────────┼─────────┤
│ 1 │ Marc │ m@mail.fr │ │ 1 │ 1 │ Google │ applied │
│ 2 │ Alice │ a@mail.fr │ │ 2 │ 1 │ Meta │ interview│
└────┴──────────┴───────────┘ │ 3 │ 2 │ Stripe │ applied │
└────┴─────────┴──────────┴─────────┘
user_id dans applications fait référence à id dans users → c'est une relation.
| Base relationnelle | Type | Usage typique |
|---|---|---|
| PostgreSQL | Open-source | Le standard moderne (#1 recommandé) |
| MySQL | Open-source | Legacy, WordPress, PHP |
| SQLite | Fichier local | Prototypage, mobile, embarqué |
| SQL Server | Microsoft | Entreprise .NET |
Bases NoSQL
Données en documents JSON (pas de tables rigides) :
\{
"_id": "user_001",
"name": "Marc",
"email": "marc@mail.fr",
"applications": [
\{ "company": "Google", "status": "applied", "date": "2026-03-01" \},
\{ "company": "Meta", "status": "interview", "date": "2026-03-10" \}
]
\}
| Base NoSQL | Type | Usage typique |
|---|---|---|
| MongoDB | Documents JSON | Startups, prototypage rapide |
| Redis | Clé-valeur (RAM) | Cache, sessions, temps réel |
| Firebase | Documents + realtime | Apps mobiles, prototypage |
| DynamoDB | Clé-valeur (AWS) | Scale massif, serverless |
SQL vs NoSQL — Comment choisir ?
| Critère | SQL (PostgreSQL) | NoSQL (MongoDB) |
|---|---|---|
| Structure | Fixe (schéma) | Flexible (sans schéma) |
| Relations | Excellentes (JOIN) | Limitées |
| Transactions | ACID garanties | Dépend du provider |
| Scalabilité | Verticale | Horizontale |
| Quand ? | Données structurées, relations complexes | Données variables, prototypage rapide |
| Analogie Marc | "Un tableur Excel avec des formules entre feuilles" | "Des dossiers de notes avec des post-its" |
Le conseil pragmatique
En cas de doute, choisissez PostgreSQL. C'est le choix par défaut de l'industrie en 2026. Il gère aussi le JSON (JSONB) si vous avez besoin de flexibilité NoSQL. Marc : "PostgreSQL, c'est comme investir dans un ETF world — ça marche pour 95% des cas."
🏋️ Exercice pratique (15 minutes)
Dessinez le schéma de base de données de votre Job Tracker :
- →Table
users: id, name, email, created_at - →Table
applications: id, user_id, company, position, status, applied_date, notes - →Identifiez la relation entre les deux tables
Quelle est la principale différence entre SQL et NoSQL ?
Pour une application de e-commerce avec des commandes, produits et clients liés entre eux, quel type de base ?
Pourquoi PostgreSQL est-il le choix recommandé par défaut en 2026 ?