Como você projeta schemas no MongoDB?

Question

Accepted Answer

O design de schema no MongoDB se concentra em uma decisão-chave: **embedding** (armazenar dados relacionados dentro de um documento) vs **referencing** (armazenar dados relacionados em documentos/coleções separadas com referências). Diferentemente do SQL que normaliza por padrão, o design do MongoDB otimiza para como os dados são *acessados*.

## Embedding — armazenar dados relacionados juntos

```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)
```

**Embedding** mantém dados relacionados em um documento — leia tudo em uma única query (rápido, sem joins). Bom para dados acessados juntos e relações "contém".

## Referencing — vincular documentos separados

```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
```

**Referencing** armazena dados separadamente e vincula por id (como uma chave estrangeira) — consulte separadamente ou junte com `$lookup`.

## Quando fazer embedding vs referencing

```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)
```

## Design para padrões de acesso (o princípio-chave)

```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.
```

## Por que isso importa

O design de schema é criticamente importante no MongoDB — é diferente e arguably mais consequente do que no SQL, porque o modelo de documento flexível do MongoDB oferece escolhas que afetam significativamente a performance e manutenibilidade, então entendê-lo é essencial para construir aplicações MongoDB eficazes.

A decisão central — **embedding vs referencing** — é a escolha de design definda do MongoDB: **embedding** (armazenar dados relacionados dentro de um documento) habilita leituras rápidas de uma única query de dados relacionados (sem joins) e é adequado para dados acessados juntos e relações "contém", enquanto **referencing** (vincular documentos separados por id) é adequado para dados grandes/ilimitados, dados acessados independentemente e relações compartilhadas/múltiplas.

Entender **quando usar cada um** (embed para dados limitados, acessados juntos, possuídos; referência para dados grandes/crescentes, independentes, compartilhados ou múltiplos — e estar atento ao limite de tamanho de documento de 16MB do MongoDB) é a habilidade-chave.

Mais importante, entender o princípio norteador — **design para padrões de acesso** (estruturar dados em torno de *como você consulta*, para que queries comuns sejam eficientes, frequentemente uma leitura de documento único, em vez de normalizar por padrão como SQL) — é o que distingue um bom design de schema no MongoDB.

Isso pode significar aceitar alguma **denormalização** (duplicação) para eficiência de leitura, um trade-off contra complexidade de atualização que é aceitável e frequentemente correto no MongoDB.

Como o design de schema afeta profundamente a performance e manutenibilidade de aplicações MongoDB (uma escolha ruim de embed/reference causa queries lentas, documentos enormes ou complexidade de atualização), e como a abordagem orientada por padrões de acesso, embed-vs-referencing é fundamentalmente diferente da normalização SQL, entender o design de schema no MongoDB — a decisão embed/reference, quando usar cada um e design para padrões de acesso — é conhecimento essencial e de alto valor para construir aplicações MongoDB eficazes, um dos tópicos MongoDB mais importantes e distintos que separa aqueles que projetam bons schemas de documentos daqueles que ingenuamente portam designs relacionais.