Schémas dynamiques vs statiques dans MongoDB

🧱 Schémas dynamiques

Exemple : blog avec schéma dynamique

Considérons un blog dans lequel les utilisateurs peuvent ajouter des articles avec des champs variables. Un article peut recevoir de nouveaux attributs au fil du temps sans migration rigide.

{
  _id: ObjectId("id_article1"),
  titre: "Introduction à MongoDB",
  contenu: "...",
  auteur: "John Doe",
  date_publication: ISODate("2023-01-01T12:00:00Z"),
  tags: ["MongoDB", "NoSQL", "Base de données"]
}

Dans cet exemple, le document peut évoluer selon les besoins. Certains articles auront un tableau tags, d'autres un champ resume ou categorie, sans imposer une structure identique partout.

🧱 Schémas statiques

Exemple : catalogue de produits avec schéma plus stable

Imaginons un catalogue où chaque produit doit toujours contenir les mêmes informations métier : nom, description, prix, catégorie et stock.

{
  _id: ObjectId("id_produit1"),
  nom: "Laptop",
  description: "Ordinateur portable performant",
  prix: 1200,
  categorie: "Informatique",
  stock: 8
}

Dans ce cas, même si MongoDB n'impose pas ce schéma par défaut, l'application adopte volontairement une structure plus stable pour garantir la cohérence des données.

🍃 Conclusion

• Les schémas dynamiques sont adaptés quand la structure peut évoluer rapidement.
• Les schémas plus stables conviennent mieux quand la validation et la cohérence priment.
• En pratique, MongoDB permet souvent un compromis : flexible côté base, validé côté application.