Quais são os padrões comuns de modelagem de dados do MongoDB?

Question

Accepted Answer

Além da decisão básica de incorporar versus referenciar, MongoDB tem **padrões de modelagem de dados** estabelecidos — soluções comprovadas para cenários comuns como arrays grandes, dados polimórficos e relacionamentos. Conhecê-los ajuda você a projetar schemas eficazes para situações reais.

## O padrão Bucket — agrupar dados de série temporal/relacionados

```js
// instead of one document per reading (millions of tiny docs), BUCKET them:
{
  sensorId: "s1",
  date: ISODate("2024-01-15"),
  readings: [                            // a day's readings in one document
    { time: "10:00", value: 23 },
    { time: "10:01", value: 24 }
  ]
}
// → fewer documents, efficient for time-series/IoT data
```

## O padrão Subset — incorporar um subconjunto frequentemente usado

```js
// embed the most-used part, reference the rest (for large related data)
{
  _id: ObjectId("..."),
  title: "Product",
  recentReviews: [ /* 5 most recent — embedded for fast display */ ],
  // full reviews live in a separate collection (referenced)
}
// → fast common reads without loading ALL related data
```

## O padrão Computed — pré-computar e armazenar

```js
// store precomputed values (avoid recomputing on every read)
{ productId: "p1", totalReviews: 1500, avgRating: 4.5 }
// → update these when reviews change; reads are fast (no aggregation needed)
```

## O padrão Extended Reference — incorporar campos de referência-chave

```js
// embed the OFTEN-NEEDED fields of a referenced document (avoid a join for common reads)
{ orderId: "o1", customer: { _id: "u1", name: "Ann", city: "NY" } }  // enough for display
// → reference customer._id for full data; embed name/city for the common read
```

## Outros padrões

```text
Polymorphic    → different document shapes in one collection (with a "type" field)
Schema Versioning → a version field to handle evolving schemas in one collection
Outlier        → handle rare documents that don't fit the common pattern specially
Approximation  → store approximate values (e.g. view counts) to reduce write load
Tree/Hierarchy → patterns for hierarchical data (parent refs, arrays of ancestors, etc.)
```

## Por que isso importa

Compreender padrões comuns de modelagem de dados do MongoDB é valioso para **projetar schemas eficazes para cenários do mundo real**, então é conhecimento útil que se constrói sobre a decisão básica de incorporar versus referenciar.

Enquanto incorporar versus referenciar é a escolha central, aplicações reais enfrentam desafios recorrentes de modelagem que esses padrões comprovados resolvem: o **padrão Bucket** (agrupar leituras de série temporal/IoT em menos documentos — importante para o caso de uso comum de série temporal, evitando milhões de documentos minúsculos), o **padrão Subset** (incorporar um subconjunto frequentemente usado enquanto se referencia aos dados completos — equilibrando desempenho de leitura com tamanho do documento para dados grandes relacionados), o **padrão Computed** (pré-computar e armazenar valores como totais/médias para evitar recomputação cara em leituras), o **padrão Extended Reference** (incorporar campos frequentemente necessários de documentos referenciados para evitar joins em leituras comuns — um híbrido prático), e outros (polimórfico para formas variadas, versionamento de schema para evolução, padrões de árvore para hierarquias).

Conhecer esses padrões fornece **soluções comprovadas** para cenários comuns em vez de reinventar designs, ajudando você a tomar decisões de modelagem sólidas para situações como dados de série temporal, grandes coleções relacionadas, computações caras e dados hierárquicos.

Como aplicações MongoDB reais enfrentam esses desafios recorrentes de design, e como padrões estabelecidos fornecem soluções testadas e eficazes (melhorando desempenho e manutenibilidade), compreender padrões comuns de modelagem de dados do MongoDB — os padrões bucket, subset, computed, extended reference e outros — é conhecimento valioso, praticamente relevante, que eleva o design de schema de escolhas básicas de incorporação/referência para aplicação de soluções comprovadas para cenários reais, refletindo habilidade madura de design do MongoDB e ajudando a construir schemas que funcionam bem para os padrões de acesso específicos e características de dados de uma aplicação.