Une considération importante lors de la conception d'un schéma pour MongoDB n'est pas ce que sont vos données, mais comment vous allez les utiliser. Sans déterminer le type de lectures et d'écritures que vous ferez (et leur performance), il peut être difficile de concevoir un schéma "optimal".
Il existe quelques directives de base que vous pouvez prendre en compte pour éviter de rencontrer des problèmes. L'un d'eux est d'éviter de concevoir des documents qui ne cessent de croître sans limite. Cela signifie que vous ne devez pas intégrer les commandes dans les documents client. Une autre règle est que les choses qui ne sont pas "intéressantes" par elles-mêmes (ou qui n'existent pas par elles-mêmes) sont probablement mieux intégrées. Cela suggère que les articles de commande ne méritent pas leur propre collection et doivent simplement être traités comme des attributs de commandes (ce qu'ils sont, en fait).
Cet exercice exact est couvert dans la formation des développeurs MongoDB, étant un exemple assez typique de conception de schéma.
L'essentiel est que vous devriez avoir trois collections :
Produits
Clients
Commandes
Les commandes référenceront les clients (en dénormalisant éventuellement certaines informations de la collecte des clients) et elles référenceront les produits (dans le tableau des articles de commande qu'elles contiendront).
D'autres collections et les champs exacts de toutes ces collections dépendent de votre cas d'utilisation spécifique, mais je ne vois pas de scénario réalisable pour avoir moins de collections que ces trois.
