A data model describes how an application organizes the data it stores and retrieves: document fields, collections, and relationships. MongoDB lets documents have different fields and types, but that flexibility does not remove the need to plan. Design around how the application accesses data, then revisit the model as requirements change. section 5.0 section 5.6
Plan the model before deploying at production scale:
- List the workload. For each important query, record the user action, whether it reads or writes, the fields involved, its frequency, and its priority. Include likely future operations. section 5.1 section 5.1.1
- Map relationships among objects and decide which document shapes belong together. Keep similar documents in the same collection; mixing unrelated shapes complicates application logic and aggregation pipelines. section 5.1 section 2.6.1
- Choose schema design patterns for the access patterns and costs you identified. Add indexes to support queries, and use collection-level schema validation where field types or values need rules. section 5.1 section 5.6
Modeling flight routes
An airline route application adds routes, searches by source and destination airports, updates route details, and checks route information. Its workload table makes the frequent reads visible before the route documents are designed. A route can keep a small, frequently accessed subset of airport information rather than a full airport document; this reduces retrieved document size but means airport changes may also require route updates. An airport document can instead keep a computed total_flights value to move repeated calculation from reads to writes. Choose between such patterns by weighing read performance, write work, duplication, and maintenance. section 5.1.1 section 5.1.3 section 5.3
Table 5.1 The workload necessary for an application
| Action |
Type |
Information |
Frequency |
Priority |
| Add new route. |
Write |
|
150 per day |
High |
| Search flight routes. |
Read |
|
22,000 per day |
High |
| Update route details. |
Write |
|
100 per day |
Medium |
| Check route information. |
Read |
|
40,000 per day |
High |
Use the route workload table to see how actions, fields, frequency, and priority inform modeling decisions. section 5.1.1
Store related data together when it fits the workload. Embedded documents and arrays can reduce the need for multidocument transactions, which generally cost more than single-document writes; transactions are not a substitute for schema design. Review and refactor collections as the application evolves. For event-driven applications, the same flexible document model can represent event objects in streams and stored data. section 8.4.3 section 2.6.1 section 15.3
