Chapter 2 of 8 · 5 practices · 3 min · 4-question quiz
Schema design
Designing documents around how the application reads and writes data, and avoiding the anti-patterns the MongoDB docs call out.
Start: Design documents around your queries, not around tables5 practices in this chapter
- 1Design documents around your queries, not around tablesThe core rule in the MongoDB data modelling docs is: data that is accessed together should be stored together. Before designing collections, list the application's main operations and how often each…
- 2Embed what you read together; reference what grows or is sharedBoth embedding and referencing are valid. Choose per relationship: The MongoDB docs give a useful hybrid: keep the five most recent reviews embedded in the product document for the product page, and…
- 3Never let an array grow without boundA BSON document can be at most 16 MiB. An array that grows with every event, such as all log lines for a device, every follower of an account or every message in a chat, eventually hits that limit…
- 4Avoid bloated documents and collection sprawlTwo more anti-patterns from the MongoDB docs: Bloated documents. When a document carries large fields that most queries do not need (a long description, a base64 image, a full audit trail), every…
- 5Add a schema version field and migrate lazily or in batchesFlexible documents let old and new shapes live side by side, which is handy during a change and confusing a year later. Add a
schemaVersionfield so code can tell which shape it is reading.
Check yourself on this chapter
4 questions, right here once you are signed in. Your progress is saved as you read.