¿Cómo diseñas esquemas en MongoDB?

Question

Accepted Answer

El diseño de esquemas en MongoDB se centra en una decisión clave: **incrustación** (almacenar datos relacionados dentro de un documento) vs **referencia** (almacenar datos relacionados en documentos/colecciones separadas con referencias). A diferencia de la normalización por defecto de SQL, el diseño de MongoDB optimiza cómo se *accede* a los datos.

## Incrustación — almacenar datos 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)
```

**La incrustación** mantiene datos relacionados en un documento — léelos todo en una sola consulta (rápido, sin joins). Es adecuada para datos accedidos juntos y relaciones de "contiene".

## Referencia — 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
```

**La referencia** almacena datos por separado y vincula por id (como una clave externa) — consulta por separado o une con `$lookup`.

## Cuándo incrustar vs hacer referencia

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

## Diseña para patrones de acceso (el principio clave)

```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 qué es importante

El diseño de esquemas es críticamente importante en MongoDB — es diferente y argumentablemente más consecuente que en SQL, porque el modelo de documento flexible de MongoDB te da opciones que afectan significativamente el desempeño y la mantenibilidad, así que comprenderlo es esencial para construir aplicaciones MongoDB efectivas.

La decisión central — **incrustación vs referencia** — es la decisión de diseño definitoria de MongoDB: **la incrustación** (almacenar datos relacionados dentro de un documento) permite lecturas rápidas de datos relacionados en una sola consulta (sin joins) y se adapta a datos accedidos juntos y relaciones de "contiene", mientras que **la referencia** (vincular documentos separados por id) se adapta a datos grandes/no acotados, datos accedidos independientemente, y relaciones compartidas/muchas.

Comprender **cuándo usar cada una** (incrustar para datos acotados, accedidos juntos, poseídos; hacer referencia para datos grandes/crecientes, independientes, compartidos, o muchas relaciones — y siendo consciente del límite de 16MB de tamaño de documento de MongoDB) es la habilidad clave.

Más importante aún, comprender el principio rector — **diseña para patrones de acceso** (estructura los datos alrededor de *cómo los consultas*, para que las consultas comunes sean eficientes, a menudo una lectura de documento única, en lugar de normalizar por defecto como SQL) — es lo que distingue el buen diseño de esquema de MongoDB.

Esto puede significar aceptar algo de **desnormalización** (duplicación) por eficiencia de lectura, un compromiso contra la complejidad de actualización que es aceptable y a menudo correcto en MongoDB.

Ya que el diseño de esquemas afecta profundamente el desempeño y la mantenibilidad de aplicaciones MongoDB (una mala elección incrustación/referencia causa consultas lentas, documentos enormes, o complejidad de actualización), y ya que el enfoque impulsado por patrones de acceso, incrustación vs referencia, es fundamentalmente diferente de la normalización SQL, comprender el diseño de esquema de MongoDB — la decisión incrustación/referencia, cuándo usar cada una, y diseñar para patrones de acceso — es conocimiento esencial de alto valor para construir aplicaciones MongoDB efectivas, uno de los temas más importantes y distintivos de MongoDB que separa a quienes diseñan buenos esquemas de documento de quienes ingenuamente portan diseños relacionales.