Qu'est-ce qu'une base NoSQL ?
Les bases relationnelles (MySQL, PostgreSQL…) stockent les données dans des tables avec un schéma rigide (colonnes fixes, types imposés) et relient les tables par des clés. Les bases NoSQL (« Not Only SQL ») assouplissent ce modèle pour gagner en flexibilité et en montée en charge.
Il existe plusieurs familles de NoSQL : clé-valeur (Redis), colonnes (Cassandra), graphes (Neo4j) et documents. MongoDB appartient à la famille orientée documents : c'est la plus proche de la façon dont on manipule les données dans le code (objets JSON).
Le document, unité de base
Dans MongoDB, on ne stocke pas des lignes mais des documents : des structures clé-valeur au format proche du JSON. Un document peut contenir des tableaux et des sous-documents imbriqués.
Un document (vue JSON)
{
"_id": ObjectId("652f1a..."),
"nom": "Dupont",
"adresse": { "ville": "Limoges", "cp": "87000" }, // sous-document
"commandes": [ 500, 1000 ] // tableau
}
En interne, MongoDB stocke ces documents au format BSON (Binary JSON) : une version binaire du JSON, plus compacte et enrichie de types que JSON ne connaît pas (dates, entiers 64 bits, ObjectId…).
Collections & base de données
Les documents sont regroupés dans des collections (l'équivalent des tables), elles-mêmes contenues dans une base de données. Contrairement à une table, une collection n'impose pas de schéma : deux documents d'une même collection peuvent avoir des champs différents.
| Concept | Rôle |
|---|---|
| Base de données | conteneur de collections (ex. fioul) |
| Collection | groupe de documents (ex. campagnes) |
| Document | un enregistrement (ex. une campagne) |
| Champ | une propriété du document (ex. zone) |
SQL vs MongoDB — le vocabulaire
Pour qui vient du relationnel, voici la table de correspondance des termes et des opérations.
| Monde SQL | Monde MongoDB |
|---|---|
| Table | Collection |
| Ligne / enregistrement | Document |
| Colonne | Champ |
| Clé primaire | Champ _id |
INSERT INTO | insertOne() / insertMany() |
SELECT | find() |
UPDATE | updateOne() / updateMany() |
DELETE | deleteOne() / deleteMany() |
JOIN | documents imbriqués ou $lookup |
GROUP BY | aggregate() avec $group |
Quand choisir MongoDB ?
MongoDB brille quand les données sont souples, hiérarchiques ou évolutives, et quand on veut itérer vite. Il n'est pas toujours le bon choix : pour des transactions financières complexes multi-tables, le relationnel reste souvent préférable.
- Bon terrain — catalogues, profils utilisateurs, données de capteurs, contenus variés, prototypage rapide.
- Terrain plus délicat — comptabilité stricte, données fortement relationnelles avec beaucoup de jointures.
L'écosystème MongoDB
Autour du serveur, plusieurs outils qu'on utilisera tout au long du parcours :
- mongod — le serveur de base de données (le processus qui stocke et répond).
- mongosh — le shell en ligne de commande (chapitre 2).
- MongoDB Compass — l'interface graphique pour explorer visuellement.
- Les drivers — les bibliothèques pour piloter MongoDB depuis un langage (ex. Spring Data MongoDB en Java, le paquet
mongodben Node.js). - MongoDB Atlas — l'hébergement géré dans le cloud (chapitre 17).
Notre application stockera ses données dans une base fioul, avec des collections comme campagnes, fournisseurs et utilisateurs. On commencera en local (mongod + mongosh + Compass), puis on hébergera la base sur Atlas pour que l'API Spring et l'appli Flutter s'y connectent. Le caractère « documents » tombe à pic : une campagne et ses commandes forment naturellement un seul document.
- MongoDB est une base NoSQL orientée documents (format JSON/BSON).
- Hiérarchie : base → collections → documents → champs.
- Pas de schéma imposé : souplesse + discipline.
- Écosystème : mongod, mongosh, Compass, drivers, Atlas.