Le problème est que vous sur-normalisez vos données. Une commande est définie par un client, qui vit à un certain endroit à un moment donné, paie un certain prix valable au moment de la commande (qui peut fortement changer au cours de la durée de vie de l'application et que vous devez de toute façon documenter et plusieurs d'autres paramètres qui ne sont tous valables qu'à un certain moment . Alors pour documenter une commande (jeu de mots), vous devez conserver toutes les données pour ce moment précis. Laissez-moi vous donner un exemple :
{ _id: "order123456789",
date: ISODate("2014-08-01T16:25:00.141Z"),
customer: ObjectId("53fb38f0040980c9960ee270"),
items:[ ObjectId("53fb3940040980c9960ee271"),
ObjectId("53fb3940040980c9960ee272"),
ObjectId("53fb3940040980c9960ee273")
],
Total:400
}
Maintenant, tant que ni le client ni les détails des articles ne changent, vous pouvez reproduire où cette commande a été envoyée, quels étaient les prix sur la commande et ainsi de suite. Mais que se passe-t-il maintenant si le client change d'adresse ? Ou si le prix d'un article change ? Vous devrez garder une trace de ces changements dans leurs documents respectifs. Ce serait beaucoup plus simple et suffisamment efficace pour stocker la commande comme :
{
_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}
]
}
Avec ce modèle de données et l'utilisation de pipelines d'agrégation, vous bénéficiez de plusieurs avantages :
- Vous n'avez pas besoin de suivre de manière indépendante les prix et les adresses ou les changements de nom ou les achats de cadeaux d'un client :c'est déjà documenté.
- À l'aide de pipelines d'agrégation, vous pouvez créer des tendances de prix sans avoir à stocker les données de tarification de manière indépendante. Vous stockez simplement le courant prix d'un article dans un document de commande.
- Même des agrégations complexes telles que l'élasticité-prix, le chiffre d'affaires par État/ville, etc., peuvent être effectuées à l'aide d'agrégations assez simples.
En général, il est prudent de dire que dans une base de données orientée document, chaque propriété ou champ susceptible de changer à l'avenir et ce changement créerait une signification sémantique différente doit être stocké à l'intérieur du document. Tout ce qui est susceptible de changer à l'avenir mais qui ne touche pas à la signification sémantique (le mot de passe de l'utilisateur dans l'exemple) peut être lié via un GUID.
