Designing a schema for your document model is incredibly important. It's the first step in creating a database that will be easy to use and understand for your users. A well-designed schema is also the foundation for all of your queries, which means that it has to be simple and consistent.
For example, if you have a table called customers, then each row in this table should contain the following data:
name, email address, phone number, gender, birthday (format as YYYY-MM-DD), last name (last name), city_of_birth (city), state_of_residence (state). You can include other fields if they're relevant to your application.
Once you've got your basic structure in place, then it's time to start thinking about how you'll actually store all of this data in MongoDB. MongoDB provides many different options for structuring your documents and storing them in arrays or embedded objects.
Following are 2 choices that developers have for every piece of data:
Embedding the documents
One of the best practices when using MongoDB is to embed your data as each document contains a collection of key-value pairs, where the keys are called fields and the values are called properties. Each document also has a collection of subdocuments (called children) that contain additional information about the parent document and each other.
Let's look at the pros and cons of using this approach.
When you want to access all of your related data, you can retrieve all relevant information in a single query. The best way to avoid implementing joins in application code. Update related information as a single atomic operation.
Large documents mean more overhead if most fields are not relevant. If you are embedding too much data inside a single document, you could potentially hit this limit of 16 MB
Referencing the documents
Rather than having a sub-document you can put the unique object ID to reference another document and connect them together using the $lookup operator. Referencing works similarly to the JOIN operator.
By splitting up data, you will have smaller documents You can restrict it to reach 16MB Infrequently accessed information not needed on every query Reduce the amount of duplication of data
In order to retrieve all the data in the referenced documents, a minimum of two queries or $lookup required to retrieve all the information
Following are some general rules:
- One-to-One - Prefer key-value pairs within the document
- One-to-Few - Prefer embedding
- One-to-Many - Prefer embedding
- One-to-Squillions - Prefer Referencing
- Many-to-Many - Prefer Referencing
Data modeling is one of the most important aspects of any application, let's talk and discuss the different strategies for schema modeling for your use case.
For further details please reach out to us at firstname.lastname@example.org