MongoDB does not require every document in a collection to have the same fields or data types. A document’s structure can change as an application evolves without first restructuring existing data. This helps with varied or rapidly changing information, but flexibility is not a reason to skip schema design. section 2.6.1 section 5.0
{ "title": "MongoDB 8.0 in Action" }
{ "name": "MongoDB 8.0 in Action" }
These two documents can share a collection even though one uses `title` and the other uses `name`. Whether they should share one depends on how the application queries them. section 2.6.1
Use the flexibility deliberately:
- Group documents with similar structures. Mixing unrelated shapes can make indexes less effective, validation harder, and application queries and aggregation pipelines more complex. section 2.6.1
- Plan around the workload: identify frequent reads and writes, map relationships, choose design patterns, and create indexes for important queries. section 5.1 section 5.1.1
- Add collection-level schema validation when fields need predictable types or values. By default, MongoDB rejects writes that violate its validation rules; it can instead be configured to warn. section 5.6
Plan for an airline route application
List each operation, its fields, frequency, and priority before settling on document shapes. Searching routes and checking route information are frequent reads; adding and updating routes are writes. Their different access patterns help determine what belongs together and what to index. section 5.1.1
The practical balance is to let documents evolve while keeping each collection coherent enough for efficient queries and maintainable application code. section 2.6.1 section 5.6
