MongoDB Vztah jeden k mnoha

Problém je v tom, že příliš normalizujete svá data. Objednávka je definována zákazníkem, který v daný okamžik bydlí na určitém místě, platí určitou cenu platnou v době objednávky (která se může v průběhu životnosti aplikace výrazně změnit a kterou stejně musíte dokumentovat a několik další parametry které jsou všechny platné pouze v určitém časovém okamžiku . Takže k dokumentu objednávky (zamýšlená slovní hříčka), musíte uchovat všechna data pro daný okamžik. Dovolte mi uvést příklad:

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

Nyní, pokud se nezmění ani zákazník, ani podrobnosti o položkách, můžete reprodukovat, kam byla tato objednávka odeslána, jaké byly ceny na objednávce a podobně. Ale co se teď stane, když zákazník změní adresu? Nebo když se změní cena zboží? Tyto změny byste museli sledovat v příslušných dokumentech. Bylo by to hodně jednodušší a dostatečně efektivní pro uložení objednávky jako:

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

S tímto datovým modelem a využitím agregačních kanálů máte několik výhod:

1. Nemusíte samostatně sledovat ceny a adresy nebo změny jména nebo dárkové nákupy zákazníka – je to již zdokumentováno.
2. Pomocí agregačních kanálů můžete vytvářet cenové trendy, aniž byste museli nezávisle ukládat údaje o cenách. Jednoduše uložíte aktuální cena položky v objednávkovém dokumentu.
3. Dokonce i složité agregace, jako je cenová elasticita, obrat podle státu/města a podobně, lze provést pomocí velmi jednoduchých agregací.

Obecně lze s jistotou říci, že v dokumentově orientované databázi by měla být uvnitř dokumentu uložena každá vlastnost nebo pole, které se v budoucnu změní a tato změna by vytvořila jiný sémantický význam. Vše, co se v budoucnu může změnit, ale nedotýká se sémantického významu (hesla uživatele v příkladu), může být propojeno pomocí GUID.