MongoDB Relacja jeden do wielu

Problem polega na tym, że nadmiernie normalizujesz swoje dane. Zamówienie jest definiowane przez klienta, który mieszka w określonym miejscu w danym momencie, płaci określoną cenę obowiązującą w momencie złożenia zamówienia (co może się znacznie zmienić w czasie życia aplikacji i którą i tak trzeba udokumentować i kilka inne parametry które są ważne tylko w określonym czasie . Więc dokumentuj zamówienie (gra słów zamierzona), musisz zachować wszystkie dane dla tego określonego momentu. Podam przykład:

{ _id: "order123456789",
  date: ISODate("2014-08-01T16:25:00.141Z"),
  customer: ObjectId("53fb38f0040980c9960ee270"),
  items:[ ObjectId("53fb3940040980c9960ee271"),
          ObjectId("53fb3940040980c9960ee272"),
          ObjectId("53fb3940040980c9960ee273")
         ],
 Total:400
 }

Teraz, dopóki nie zmieni się ani klient, ani szczegóły pozycji, jesteś w stanie odtworzyć, dokąd zostało wysłane to zamówienie, jakie były ceny na zamówieniu i podobne. Ale co się stanie, jeśli klient zmieni adres? Lub jeśli cena przedmiotu się zmieni? Będziesz musiał śledzić te zmiany w odpowiednich dokumentach. Byłoby dużo łatwiejsze i wystarczająco wydajne do przechowywania zamówienia, takie jak:

{
  _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}
  ]
}

Dzięki temu modelowi danych i wykorzystaniu potoków agregacji masz kilka zalet:

1. Nie musisz niezależnie śledzić cen i adresów, zmian nazwiska lub zakupów prezentów klienta — jest to już udokumentowane.
2. Korzystając z potoków agregacji, możesz tworzyć trendy cenowe bez konieczności niezależnego przechowywania danych cenowych. Po prostu przechowujesz bieżący cena towaru w dokumencie zamówienia.
3. Nawet złożone agregacje, takie jak elastyczność cenowa, obrót według stanu/miasta i tym podobne, można wykonać za pomocą dość prostych agregacji.

Ogólnie można śmiało powiedzieć, że w bazie danych zorientowanej na dokumenty każda właściwość lub pole, które może ulec zmianie w przyszłości, a zmiana ta stworzyłaby inne znaczenie semantyczne, powinna być przechowywana w dokumencie. Wszystko, co może ulec zmianie w przyszłości, ale nie zmienia znaczenia semantycznego (hasło użytkownika w przykładzie) może być połączone za pomocą identyfikatora GUID.