MongoDB Een tot veel relaties

Het probleem is dat u uw gegevens overmatig normaliseert. Een bestelling wordt gedefinieerd door een klant, die op een bepaald moment op een bepaalde plaats woont, een bepaalde prijs betaalt die geldig is op het moment van de bestelling (die sterk kan veranderen gedurende de levensduur van de aanvraag en die u toch moet documenteren en verschillende andere parameters die allemaal alleen geldig zijn op een bepaald tijdstip . Dus om te documenteren een bestelling (bedoelde woordspeling), moet u alle gegevens voor dat bepaalde tijdstip bewaren. Laat me je een voorbeeld geven:

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

Nu, zolang noch de klant, noch de details van de artikelen veranderen, kunt u reproduceren waar deze bestelling naartoe is gestuurd, wat de prijzen op de bestelling waren en gelijkaardig. Maar wat gebeurt er nu als de klant van adres verandert? Of als de prijs van een artikel verandert? U moet die wijzigingen in hun respectieve documenten bijhouden. Het zou veel zijn gemakkelijker en voldoende efficiënt om de bestelling op te slaan zoals:

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

Met dit datamodel en het gebruik van aggregatiepijplijnen heeft u verschillende voordelen:

1. U hoeft niet onafhankelijk prijzen en adressen of naamswijzigingen of cadeau-aankopen van een klant bij te houden - dit is al gedocumenteerd.
2. Met behulp van aggregatiepijplijnen kunt u prijstrends maken zonder dat u prijsgegevens afzonderlijk hoeft op te slaan. U slaat eenvoudig de huidige prijs van een artikel in een besteldocument.
3. Zelfs complexe aggregaties zoals prijselasticiteit, omzet per staat / stad en dergelijke kunnen worden gedaan met vrij eenvoudige aggregaties.

Over het algemeen is het veilig om te zeggen dat in een documentgeoriënteerde database elke eigenschap of elk veld dat in de toekomst kan worden gewijzigd en deze wijziging een andere semantische betekenis zou creëren, in het document moet worden opgeslagen. Alles wat in de toekomst aan verandering onderhevig is maar de semantische betekenis niet raakt (het gebruikerswachtwoord in het voorbeeld) kan via een GUID worden gekoppeld.