Du kan undgå N+1 -problem med hundredvis af anmodninger, der bruger $in
-forespørgsler. Overvej dette:
Post {
PosterId: ObjectId
Text: string
Comments: [ObjectId, ObjectId, ...] // option 1
}
Comment {
PostId: ObjectId // option 2 (better)
Created: dateTime,
AuthorName: string,
AuthorId: ObjectId,
Text: string
}
Nu kan du finde indlægskommentarerne med en $in forespørgsel, og du kan også nemt finde alle kommentarer fra en bestemt forfatter.
Du kan selvfølgelig også gemme kommentarerne som et indlejret array i posten og udføre en $in forespørg på brugeroplysningerne, når du henter kommentarerne. På den måde behøver du ikke at denormalisere brugernavne og stadig ikke have brug for hundredvis af forespørgsler.
Hvis du vælger at denormalisere brugernavnene, bliver du nødt til at opdatere alle kommentarer, der nogensinde er lavet af den pågældende bruger, når en bruger ændrer f.eks. hans navn. På den anden side, hvis sådanne operationer ikke forekommer særlig ofte, burde det ikke være en stor sag. Eller måske er det endnu bedre at gemme det navn, brugeren havde, da han lavede kommentaren, afhængigt af dine krav.
Et generelt problem med indlejring er, at forskellige forfattere vil skrive til det samme objekt
, så du bliver nødt til at bruge atomic modifiers
(såsom $push ). Dette er nogle gange sværere at bruge med kortlæggere (jeg kender dog ikke mongoalchemy), og generelt mindre fleksibelt.