Il problema è che normalizzi eccessivamente i tuoi dati. Un ordine è definito da un cliente, che risiede in un determinato luogo in un determinato momento, paga un determinato prezzo valido al momento dell'ordine (che potrebbe cambiare pesantemente nel corso della durata dell'applicazione e che devi comunque documentare e diversi altri parametri tutti validi solo in un determinato momento . Quindi per documentare un ordine (gioco di parole), è necessario mantenere tutti i dati per quel determinato momento. Ti faccio un esempio:
{ _id: "order123456789",
date: ISODate("2014-08-01T16:25:00.141Z"),
customer: ObjectId("53fb38f0040980c9960ee270"),
items:[ ObjectId("53fb3940040980c9960ee271"),
ObjectId("53fb3940040980c9960ee272"),
ObjectId("53fb3940040980c9960ee273")
],
Total:400
}
Ora, finché né il cliente né i dettagli degli articoli cambiano, puoi riprodurre dove è stato inviato questo ordine, quali erano i prezzi sull'ordine e simili. Ma ora cosa succede se il cliente cambia indirizzo? O se il prezzo di un articolo cambia? Dovresti tenere traccia di tali modifiche nei rispettivi documenti. Sarebbe molto più facile e sufficientemente efficiente per memorizzare l'ordine come:
{
_id: "order987654321",
date: ISODate("2014-08-01T16:25:00.141Z"),
customer: {
userID: ObjectId("53fb3940040980c9960ee283"),
recipientName: "Foo Bar"
address: {
street: "742 Evergreen Terrace",
city: "Springfield",
state: null
}
},
items: [
{count:1, productId:ObjectId("53fb3940040980c9960ee300"), price: 42.00 },
{count:3, productId:ObjectId("53fb3940040980c9960ee301"), price: 0.99},
{count:5, productId:ObjectId("53fb3940040980c9960ee302"), price: 199.00}
]
}
Con questo modello di dati e l'utilizzo di pipeline di aggregazione, hai diversi vantaggi:
- Non è necessario tenere traccia in modo indipendente di prezzi e indirizzi o cambi di nome o acquisti di regali di un cliente:è già documentato.
- Utilizzando le pipeline di aggregazione, puoi creare un andamento dei prezzi senza la necessità di archiviare i dati sui prezzi in modo indipendente. Devi semplicemente memorizzare la corrente prezzo di un articolo in un documento d'ordine.
- Anche aggregazioni complesse come l'elasticità del prezzo, il fatturato per stato/città e simili possono essere eseguite utilizzando aggregazioni piuttosto semplici.
In generale, è sicuro affermare che in un database orientato al documento, ogni proprietà o campo che è soggetto a modifiche in futuro e questa modifica creerebbe un significato semantico diverso dovrebbe essere memorizzata all'interno del documento. Tutto ciò che è soggetto a modifiche in futuro ma non tocca il significato semantico (nell'esempio la password dell'utente) può essere collegato tramite un GUID.
