MongoDB en till många relation

Problemet är att du övernormaliserar din data. En beställning definieras av en kund, som bor på en viss plats vid den givna tidpunkten, betalar ett visst pris som gäller vid beställningstillfället (som kan förändras kraftigt under applikationens livslängd och som du ändå måste dokumentera och flera andra parametrar som alla är giltiga endast under en viss tidpunkt . Så för att dokumentera en beställning (ordlek avsedd), måste du bevara all data för den specifika tidpunkten. Låt mig ge dig ett exempel:

{ _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 varken kunden eller detaljerna i varorna ändras, kan du återge var denna beställning skickades till, vilka priser på beställningen var och liknande. Men vad händer nu om kunden ändrar sin adress? Eller om priset på en vara ändras? Du skulle behöva hålla reda på dessa ändringar i deras respektive dokument. Det skulle vara mycket enklare och tillräckligt effektivt för att lagra beställningen 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 denna datamodell och användningen av aggregeringspipelines har du flera fördelar:

1. Du behöver inte självständigt hålla reda på priser och adresser eller namnändringar eller presentköp av en kund – det är redan dokumenterat.
2. Med hjälp av aggregeringspipelines kan du skapa pristrender utan att behöva lagra prisdata oberoende. Du lagrar helt enkelt den aktuella pris på en vara i ett beställningsdokument.
3. Även komplexa aggregationer som priselasticitet, omsättning per stat/stad och liknande kan göras med ganska enkla aggregationer.

I allmänhet är det säkert att säga att i en dokumentorienterad databas bör varje egenskap eller fält som kan ändras i framtiden och denna förändring skulle skapa en annan semantisk betydelse lagras i dokumentet. Allt som kan komma att ändras i framtiden men som inte berör den semantiska betydelsen (användarens lösenord i exemplet) kan länkas via en GUID.