Als fervent mongodb-fan raad ik je aan een relationele database te gebruiken voor zeer relationele gegevens - daar is het voor gebouwd. Je verliest alle voordelen van mongodb wanneer je 3+ queries moet uitvoeren om een enkel object te krijgen.
Buuuuuut , Ik weet dat die opmerking aan dovemansoren gericht zal zijn. Uw beste gok is om zo bewust mogelijk te zijn over prestaties. Uw eerste stap is om de velden te beperken tot het vereiste minimum. Dit is gewoon een goede gewoonte, zelfs met basisvragen en elke database-engine - krijg alleen de velden die u nodig hebt (bijv. SELECT * FROM ===slecht... stop er gewoon mee!). U kunt ook proberen om lean-query's uit te voeren om veel nabewerkingswerk te besparen dat mangoest met de gegevens doet. Ik heb dit niet getest, maar het zou moeten werken...
SchemaA.find({}, 'field1 fieldB', { lean: true })
.populate({
name: 'fieldB',
select: 'fieldC',
options: { lean: true }
}).exec(function (err, result) {
// not sure how you are populating "result" in your example, as it should be an array,
// but you said your code works... so I'll let you figure out what goes here.
});
Een erg "mongo"-manier om te doen wat je wilt, is om een referentie in SchemaC terug op te slaan naar SchemaA. Als ik zeg "mongo"-manier om het te doen, moet je breken met je jarenlange denken over relationele gegevensquery's. Doe wat nodig is om minder query's op de database uit te voeren, zelfs als er tweerichtingsreferenties en/of gegevensduplicatie nodig zijn.
Als ik bijvoorbeeld een Boekenschema en Auteursschema had, zou ik waarschijnlijk de voor- en achternaam van de auteur opslaan in de Boeken-verzameling, samen met een _id-verwijzing naar het volledige profiel in de Auteurs-verzameling. Op die manier kan ik mijn boeken in een enkele zoekopdracht laden, nog steeds de naam van de auteur weergeven en vervolgens een hyperlink naar het profiel van de auteur genereren:/author/{_id} . Dit staat bekend als "gegevensdenormalisatie" en het is bekend dat het mensen brandend maagzuur geeft. Ik probeer het te gebruiken voor gegevens die niet vaak veranderen, zoals de namen van mensen. In het geval dat een naam verandert, is het triviaal om een functie te schrijven om alle namen op meerdere plaatsen bij te werken.