Как вы проектируете схемы в MongoDB?

Question

Accepted Answer

Проектирование схемы в MongoDB сосредоточено на ключевом решении: **встроенные данные** (хранение связанных данных внутри документа) в сравнении с **ссылками** (хранение связанных данных в отдельных документах/коллекциях со ссылками). В отличие от SQL, который по умолчанию нормализует данные, дизайн MongoDB оптимизирован для того, как данные *используются*.

## Встроенные данные — хранение связанных данных вместе

```js
// embed related data within the document
{
  _id: ObjectId("..."),
  name: "Ann",
  address: { city: "NY", zip: "10001" },        // embedded sub-document
  orders: [                                      // embedded array of orders
    { product: "Phone", amount: 999 },
    { product: "Case", amount: 20 }
  ]
}
// → ONE query gets the user AND their address AND orders (no joins)
```

**Встроенные данные** хранят связанные данные в одном документе — прочитайте все за один запрос (быстро, без объединений). Подходит для данных, которые используются вместе, и для отношений "содержит".

## Ссылки — связывание отдельных документов

```js
// store a reference (id) to a document in another collection
{ _id: ObjectId("u1"), name: "Ann" }                          // users collection
{ _id: ObjectId("o1"), userId: ObjectId("u1"), product: "Phone" } // orders collection
// → query orders by userId; use $lookup to join when needed
```

**Ссылки** хранят данные отдельно и связывают по id (как внешний ключ) — запрашивают отдельно или объединяют с помощью `$lookup`.

## Когда использовать встроенные данные или ссылки

```text
EMBED when:
  ✓ data is accessed TOGETHER (read the parent → you want the children)
  ✓ a "contains"/ownership relationship (address, order line items)
  ✓ the embedded data is bounded (not unboundedly growing)
  ✓ one-to-few relationships

REFERENCE when:
  ✓ data is large or grows UNBOUNDEDLY (avoid huge documents — 16MB doc limit!)
  ✓ data is accessed/updated INDEPENDENTLY
  ✓ many-to-many or one-to-many with many
  ✓ the same data is shared/referenced by many documents (avoid duplication)
```

## Проектирование для паттернов доступа (ключевой принцип)

```text
MongoDB schema design is driven by HOW YOU QUERY the data, not pure normalization:
  → Structure data so common queries are efficient (often a single document read).
  → "Data that is accessed together should be stored together."
  → This may mean DENORMALIZING (some duplication) for read efficiency — acceptable
    in MongoDB, traded against update complexity.
```

## Почему это важно

Проектирование схемы критически важно в MongoDB — оно отличается от SQL и, возможно, более значимо, чем в SQL, потому что гибкая модель документов MongoDB дает вам выбор, который существенно влияет на производительность и поддерживаемость. Поэтому понимание этого является необходимым для создания эффективных приложений MongoDB.

Центральное решение — **встроенные данные в сравнении со ссылками** — это определяющий выбор при проектировании MongoDB: **встроенные данные** (хранение связанных данных внутри документа) обеспечивают быстрое чтение связанных данных в одном запросе (без объединений) и подходят для данных, которые используются вместе и имеют отношение "содержит", а **ссылки** (связывание отдельных документов по id) подходят для больших/неограниченных данных, независимо используемых данных и общих/многих отношений.

Понимание **когда использовать каждый подход** (встроенные данные для ограниченных, используемых вместе, принадлежащих данных; ссылки для больших/растущих, независимых, общих или многих отношений — и учитывая ограничение MongoDB на размер документа в 16МБ) — это ключевой навык.

Все важнее всего понимание руководящего принципа — **проектирование для паттернов доступа** (структурирование данных вокруг *того, как вы их запрашиваете*, так чтобы обычные запросы были эффективны, часто одно чтение документа, вместо нормализации по умолчанию как в SQL) — это то, что отличает хороший дизайн схемы MongoDB.

Это может означать принятие некоторой **денормализации** (дублирования) для эффективности чтения, компромисса в сравнении со сложностью обновлений, который приемлем и часто правилен в MongoDB.

Поскольку проектирование схемы глубоко влияет на производительность и поддерживаемость приложения MongoDB (плохой выбор между встроенными данными и ссылками вызывает медленные запросы, огромные документы или сложность обновлений), и поскольку подход на основе паттернов доступа, встроенные данные в сравнении со ссылками, принципиально отличается от нормализации SQL, понимание проектирования схемы MongoDB — решение встроенные данные/ссылки, когда использовать каждый подход и проектирование для паттернов доступа — это необходимое, высокоценное знание для создания эффективных приложений MongoDB, одна из наиболее важных и отличительных тем MongoDB, которая отделяет тех, кто проектирует хорошие схемы документов, от тех, кто наивно переносит реляционные схемы.