MongoDB et til mange forhold

Problemet er, at du overnormaliserer dine data. En ordre defineres af en kunde, der bor et bestemt sted på det givne tidspunkt, betaler en bestemt pris gældende på ordretidspunktet (som kan ændre sig kraftigt i løbet af ansøgningens levetid, og som du alligevel skal dokumentere og flere andre parametre som alle kun er gyldige på et bestemt tidspunkt . Så for at dokumentere en ordre (pun intended), skal du bevare alle data for det bestemte tidspunkt. Lad mig give dig et eksempel:

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

Nu, så længe hverken kunden eller detaljerne i varerne ændres, er du i stand til at gengive, hvor denne ordre blev sendt til, hvad priserne på ordren var og lignende. Men hvad sker der nu, hvis kunden ændrer sin adresse? Eller hvis prisen på en vare ændrer sig? Du skal holde styr på disse ændringer i deres respektive dokumenter. Det ville være meget nemmere og tilstrækkeligt effektivt til at opbevare ordren som:

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

Med denne datamodel og brugen af ​​aggregeringspipelines har du flere fordele:

1. Du behøver ikke selvstændigt at holde styr på priser og adresser eller navneændringer eller gavekøb af en kunde - det er allerede dokumenteret.
2. Ved at bruge aggregeringspipelines kan du oprette en pristendens uden at skulle gemme prisdata uafhængigt. Du gemmer blot den aktuelle pris på en vare i et ordredokument.
3. Selv komplekse sammenlægninger såsom priselasticitet, omsætning efter stat/by og lignende kan udføres ved hjælp af ret simple sammenlægninger.

Generelt er det sikkert at sige, at i en dokumentorienteret database, bør hver egenskab eller felt, som kan ændres i fremtiden, og denne ændring ville skabe en anden semantisk betydning, gemmes inde i dokumentet. Alt, der kan ændres i fremtiden, men som ikke berører den semantiske betydning (brugerens adgangskode i eksemplet), kan linkes via en GUID.