Проблемът е, че прекомерно нормализирате данните си. Поръчката се дефинира от клиент, който живее на определено място в дадения момент от време, плаща определена цена, валидна към момента на поръчката (която може силно да се промени през целия живот на приложението и която все пак трябва да документирате и няколко други параметри, които всички са валидни само в определен момент от време . Така че документирайте поръчка (игра на думи), трябва да запазите всички данни за този определен момент от време. Нека ви дам пример:
{ _id: "order123456789",
date: ISODate("2014-08-01T16:25:00.141Z"),
customer: ObjectId("53fb38f0040980c9960ee270"),
items:[ ObjectId("53fb3940040980c9960ee271"),
ObjectId("53fb3940040980c9960ee272"),
ObjectId("53fb3940040980c9960ee273")
],
Total:400
}
Сега, стига нито клиентът, нито детайлите на артикулите да се променят, вие можете да възпроизведете къде е изпратена тази поръчка, какви са били цените на поръчката и други подобни. Но сега какво се случва, ако клиентът промени адреса си? Или ако цената на даден артикул се промени? Ще трябва да следите тези промени в съответните им документи. Би било много по-лесно и достатъчно ефективно за съхраняване на поръчката като:
{
_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}
]
}
С този модел на данни и използването на тръбопроводи за агрегиране имате няколко предимства:
- Не е необходимо самостоятелно да следите цените и адресите или промените в името или покупките на подарък на клиент – това вече е документирано.
- С помощта на тръбопроводи за агрегиране можете да създавате ценови тенденции, без да е необходимо самостоятелно да съхранявате данни за цените. Вие просто съхранявате настоящите цена на артикул в документ за поръчка.
- Дори сложни агрегирания като ценова еластичност, оборот по щат/град и други подобни могат да бъдат направени с помощта на доста прости агрегати.
Като цяло е безопасно да се каже, че в документно ориентирана база данни, всяко свойство или поле, което подлежи на промяна в бъдеще и тази промяна би създала различно семантично значение, трябва да се съхранява в документа. Всичко, което подлежи на промяна в бъдеще, но не засяга семантичното значение (паролата на потребителите в примера), може да бъде свързано чрез GUID.
