Una considerazione importante quando si progetta uno schema per MongoDB non è quali sono i tuoi dati, ma come li utilizzerai. Senza capire che tipo di letture e scritture farai (e quanto saranno performanti) può essere difficile progettare uno schema "ottimale".
Ci sono alcune linee guida di base che puoi prendere in considerazione per evitare di incorrere in problemi. Uno di questi è evitare di progettare documenti che continuano a crescere senza limiti. Ciò significa che non dovresti incorporare gli ordini nei documenti dei clienti. Un'altra regola è che le cose che non sono "interessanti" da sole (o non esistono da sole) probabilmente è meglio che vengano incorporate. Ciò suggerisce che orderItems non merita una propria collezione e dovrebbe semplicemente essere trattato come attributi degli ordini (che è quello che sono, in effetti).
Questo esercizio esatto è trattato nella formazione per sviluppatori MongoDB, essendo un tipico esempio di progettazione di schemi.
La conclusione è che dovresti avere tre raccolte:
Prodotti
Clienti
Ordini
Gli ordini faranno riferimento ai clienti (facoltativamente denormalizzando alcune informazioni dalla raccolta dei clienti) e faranno riferimento ai prodotti (nell'array di orderItem che conterranno).
Ulteriori raccolte e campi esatti in tutte queste raccolte dipendono dal tuo caso d'uso specifico, ma non vedo uno scenario fattibile per avere meno raccolte di queste tre.
