0Pricing
MongoDB Academy · 课时

模式设计决策框架

您将应用结构化检查清单——查询模式、写入频率和文档增长情况——为任何领域选择嵌入或引用。

模式设计决策框架 是 CoddyKit 上的免费 MongoDB Academy 课时。 这是第 4 节课，共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 MongoDB Academy 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 MongoDB Academy 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

Why a Decision Framework Matters

MongoDB's schema flexibility is powerful but can lead to analysis paralysis. Should you embed or reference? When is the choice not obvious? A structured decision framework replaces guesswork with a repeatable checklist. By asking the same questions about query patterns, write frequency, and document growth, you can arrive at the right schema for any domain—consistently.

Step 1: Identify Query Patterns

Start by listing the most frequent read queries your application makes. Ask: do these queries always need the parent and children together, or are children queried independently? If child data is almost always fetched with its parent, embedding eliminates a round trip. If children are frequently queried, sorted, or filtered on their own, referencing keeps queries simple and indexes focused.

Step 2: Estimate Data Size and Growth

For every potential array or nested structure, ask: how many elements will this have at steady state, and can it grow without bound? Use rough business rules: a user rarely has more than 5 addresses (embed), but can write thousands of reviews (reference). Anything with an unbounded or unknown upper limit is a candidate for a separate collection.

Step 3: Evaluate Write Frequency

Consider how often the child data is written compared to the parent. Embedding means every child update rewrites the parent document, triggering a storage move if the document grows. If children are updated very frequently and independently of the parent, the overhead of rewriting the parent each time favours referencing—child documents update in place without touching the parent at all.

Step 4: Check for Data Sharing

Ask whether the child data is owned by one parent or shared across multiple parents. An address is owned by a single user—safe to embed. A product in a catalogue is referenced by potentially thousands of orders—it must be in its own collection to avoid duplication and stale data. Shared data should always be referenced, never embedded.

Step 5: Assess Atomicity Requirements

MongoDB guarantees atomic writes at the document level for free—no transactions needed. If you need to update a parent and its children atomically, embedding keeps both in the same document so any update is atomic by default. If you reference across two collections and need atomicity, you must use a multi-document transaction, which adds latency and complexity.

The Framework Decision Table

Apply these rules in order:

  • Children always fetched with parent + small count + owned by parent: EMBED
  • Children queried independently or shared: REFERENCE
  • Children can grow without bound: REFERENCE (or bucket pattern)
  • Atomic update required across parent + children: EMBED (or transaction)
  • Write frequency of children high relative to parent: REFERENCE

If multiple rules conflict, referencing is the safer default.

Example: E-Commerce Order Schema

Apply the framework to an order in an e-commerce system. Line items: always fetched with order, small count (under 50), owned by order → embed. Shipping address: snapshot at order time, never shared → embed. Customer: shared across thousands of orders → reference. Product catalogue: shared across orders, updated independently → reference.

db.orders.insertOne({
  _id: ObjectId(),
  customerId: ObjectId('c1'),        // reference — shared data
  shippingAddress: {                 // embed — point-in-time snapshot
    street: '123 Maple St',
    city: 'Austin'
  },
  items: [                           // embed — small, owned by order
    { productId: ObjectId('p1'), qty: 2, price: 19.99, name: 'Widget' }
  ]
});

Example: Social Media Schema

Apply the framework to a social media post. Post author: shared across posts → reference. Post body and metadata: owned by post, small → embed. Likes (count only): numeric field → embed as a counter. Comments: potentially thousands, queried and paginated independently → reference in a separate comments collection.

db.posts.insertOne({
  _id: ObjectId(),
  authorId: ObjectId('u1'),           // reference
  title: 'Why MongoDB rocks',
  body: '<p>Because documents...</p>',
  tags: ['mongodb', 'nosql'],         // embed — small, owned
  likesCount: 0,                      // embed — simple counter
  createdAt: new Date()
  // comments live in db.comments, NOT embedded here
});

Evolving Your Schema Over Time

The right schema at launch may not be the right schema at scale. Start with the simplest correct design. If you later discover that an embedded array is growing too large, migrate it to a separate collection. MongoDB's flexible schema makes incremental evolution possible—you can write new documents in the new shape while keeping old ones, then backfill with a migration script.

Documenting Your Schema Decisions

Write down the reasoning behind each schema choice while it is fresh. A comment in a Mongoose schema file or a short design document explaining why items are embedded but customerId is referenced pays enormous dividends when a new engineer joins or when you revisit the schema six months later. Schema design is a deliberate act, not an accident.

const orderSchema = new mongoose.Schema({
  customerId: { type: mongoose.Schema.Types.ObjectId, ref: 'Customer' }, // reference: shared
  shippingAddress: addressSchema,  // embed: point-in-time snapshot
  items: [lineItemSchema],         // embed: small, always with order
  status: { type: String, enum: ['pending', 'shipped', 'delivered'] },
  createdAt: { type: Date, default: Date.now }
});

Quick Check

Test your understanding of MongoDB & NoSQL Databases concepts from this lesson.

Lesson Recap

In this lesson you learned: the five-step decision framework covers query patterns, data size, write frequency, sharing, and atomicity, shared data always belongs in a separate referenced collection, and schema decisions should be documented alongside the code. Next up we explore schema validation with JSON Schema to enforce data quality in MongoDB collections.

常见问题解答

「模式设计决策框架」课时是免费的吗？

是的 — 「模式设计决策框架」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 MongoDB Academy 课程的其余内容，请升级到 CoddyKit PRO。 MongoDB Academy 课程共包含 4 节课。

「模式设计决策框架」这节课中我会学到什么？

您将应用结构化检查清单——查询模式、写入频率和文档增长情况——为任何领域选择嵌入或引用。 你通过在浏览器中直接运行的动手代码来练习 MongoDB Academy，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 MongoDB Academy 需要有经验吗？

无需任何先前经验。CoddyKit 上的 MongoDB Academy 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。 这是第 4 节课，共 4 节。

「模式设计决策框架」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 MongoDB Academy 课中编写并运行代码吗？

能。每节 MongoDB Academy 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

  1. 嵌入：一对少关系
  2. 引用：一对多与多对多
  3. 无界数组反模式
  4. 模式设计决策框架
← 返回 MongoDB Academy