Tree patterns - using both child reference and parent reference

I’ve been wondering whether using both patterns is valid in any use case?

Hey @Anh_95344

Do you mean having both parent and child references at the same time?

I have been trying to think of some situations where this might apply. And with a tree structure I am not sure… Why I say that is that no matter which way you reference, either child or parent, the query language has a way of retrieving the documents

Consider maybe a Database with Movies Collection and Actors Collection. Since a Movie has many actors, and an actor can be in multiple movies you could make the case for what your asking. Therefore you could have an array of Actor _ids or names in the Movie Document and on the Actor Documents you could have an array of Movie _ids.
However when building your queries I think you will see that there is some redundancy going on.

Say we want to fetch all movies that an Actress was in.

// fetch all the movies that have the given actorId in the actor array field
  actors: { $eq: actorId }

// take the movies field(array containing movie _ids) on the Actor document and use $lookup to find the movies that match, and put the results in a field called movieDetails 
    $match: { '_id': actorId }
    $lookup: {
      from: 'movies',
      localField: 'movies',
      foreignField: '_id', // could also be title or however you referenced them
      as: 'movieDetails'

So this example hopefully shows that we can find the movies an Actress was in with either reference.

Again to stress the most important point when it comes to modelling your data with Mongodb is the access patterns of your application. It seems like one of those skills that gets perfected over trial and error. :slightly_smiling_face:

Hope this helps



The Tree Pattern is useful to represent data that is hierarchic and has more than two levels. A good way to answer if the data is a tree (or network) is to see if you can recurse on the data.
Good examples of hierarchical data would be:

  • relationship with your mother and father. You can follow this relationship another level to find your grandparents, then another level to find your great grandparents.
  • reporting chains. One can find your manager, then the manager of your manager, all the way to the CEO of your organization.
  • social network relationships. One can find everyone you know through your direct contacts, meaning who can get a list of the people your direct contacts can introduce you to.

Each variant of the Tree Pattern may be a better candidate for a given use case, than another.

For example, the “ancestors” variant works well for data that does not change often.
However, for more dynamic data, a direct link to the parent(s) avoid rebuilding the chains of relationships.

Could you have more than one Tree Pattern variant for a given application?
Let’s say we want to model a social network that keeps track of people, their jobs and the people they know.
Each person may be represented as a document, in which there is a static hierarchical list of business domains. For example, I work for a data/database software company that may be listed under this tree:

“domain”: [“Business”, “Technology”, “Software”, “Database”]

Also, we want to keep track of my position in my organization:

“reports_to”: “Shannon”

For the “domain”, we use the “ancestors” form of the Tree Pattern. It makes sense because this is computed once in a while and rarely change.
On the other hand, for the “reports_to” field, we may have elected to only keep the direct manager because the users of the system are usually not interested in seeing higher levels and our company has reorganizations every week and we simply want to update the direct relationships that need to, not the full chains to the CEO for all users.


1 Like