How to work with Embedded documents and References in MongoDB
Overview
MongoDB is a NoSQL database and does not support classic relationships as in SQL databases. However, you can build references across entities in MongoDB in a couple of ways -
Inner objects (equivalent to embedded documents, i.e., documents nested within another document)
References across collections using an ObjectID field in a collection to reference an ID in another collection
For a more comprehensive overview on this topic, refer to MongoDB's docs on Embedded Data Versus References. In this guide, we will see how you can work with inner objects and references in MongoDB with Neurelo.
Inner Objects (Embedded Documents)
An embedded document in MongoDB is a document nested inside another MongoDB document. That is, it is not just a reference to another document but it is fully contained within the parent document.
In the Neurelo Schema Language and in the APIs, embedded documents can be used as innerObjects.
For example, consider the following document
Here, nutritionalInfo
is an inner object.
Inner objects enhance read performance by reducing database queries and ensuring atomic updates within a single document. They are optimal for closely related data that is frequently accessed together, remains relatively static, and adheres to the 16MB MongoDB document size limit. However, they might lead to data redundancy and scalability challenges as your database grows.
The Neurelo Schema for this will be something like this -
For guidance on building APIs using inner objects, refer to the API reference materials for REST and GraphQL.
References
References in MongoDB are used to link documents across different collections. This is a commonly used technique to represent one-to-one, one-to-many, or many-to-many relationships.
To do this, instead of embedding all data within a single document, we can reference data from other collections. For example, consider the following three documents from three different collections:
Here, there is a one to one reference between NutritionalInfo
and Products
. Furthermore, there is a one to many reference between Products
and Reviews
.
The Neurelo Schema for this will be something like this -
Unlike embedded documents, references are more suitable for large or frequently changing data. They excel in many-to-many relationships by offering flexibility to link documents across different collections, preventing data duplication, and maintaining database normalization. However, this approach may require additional queries to access related data, potentially affecting performance.
Now, consider the same database structure as shown in the example above. To create references using Neurelo, it is important to structure your create queries in a specific order. This will ensure that all documents are created in the correct sequence to initiate the references between them. For instance,
You can begin by creating the
NutritionalInfo
document, as this does not depend on any other documents.Next, you can create the
Products
document. Initially, you can include thenutritionalInfoId
with the ID of the previously createdNutritionalInfo
document and initialize thereviewIds
with an empty array.After this, you can proceed with creating individual
Reviews
documents, where each document references theproductId
of theProducts
document.And finally, you can update the
Products
document to include the_id
s of the newly createdReviews
documents.
For guidance on building create and update APIs, refer to the API reference materials for REST and GraphQL.
Last updated