Design a MongoDB model around the way an application reads and updates its data. Documents contain fields and values, collections group documents, and relationships can be represented through embedding or references. Flexibility is useful when it is accompanied by explicit application rules.
MongoDB modelling vocabulary
| Focus | Practical approach | Check before proceeding |
|---|---|---|
| Document | A record containing fields and values. | Keep related fields consistent with application requirements. |
| Collection | A group of documents used by the application. | Apply validation where predictable data shapes matter. |
| Relationship | A connection represented by embedding or referencing. | Choose using access patterns and update requirements. |
Begin with access patterns
List the questions each important screen asks of the database. An order detail screen needs a different shape of information from a report across thousands of orders. Include updates and background processes in the exercise. Designing only around how an object looks in application code can miss the queries that dominate production use.
Compare embedding and references
Information frequently read together may suit an embedded structure, provided its size and update behaviour remain manageable. Separately maintained entities may suit references. For an order, distinguish the historical values recorded at purchase from current product information that may later change. That distinction should be explicit regardless of storage technique.
Define validation and change rules
Identify required fields, permitted types and relationships the application must maintain. Decide how older documents are read during a model change. A flexible schema does not mean that every shape is equally useful. Invalid or ambiguous data makes reporting, support and future migrations more difficult.
Test representative data
Use realistic document sizes and relationships in the prototype. Examine common queries, growth assumptions and update frequency. Record why the selected model fits the workload and what would indicate that it needs to change. Treat indexing and backup design as part of the production plan rather than a final adjustment.
Useful next steps
For a related perspective, read MongoDB Features: Documents, Indexes and Replication, Docker and Kubernetes: Packaging and Operating Applications, How Node.js Handles I/O and CPU-Heavy Work.
If you need help applying this to your business, explore our custom software development or discuss your project.
Sources and further reading
By Tech Me Today. Originally published September 22, 2023. Expanded on .
Explore all articles →
