MongoDB
Compara embedding y referencing según cardinalidad, ownership, frecuencia de lectura, crecimiento, atomicidad, duplicación y consistencia del dominio.
Elegir entre embedding y referencing no consiste en seguir una regla universal. La decisión debe partir de los access patterns, el ownership, la cardinalidad, el crecimiento y las garantías que necesita la operación.
¿Se leen juntos?
¿Se modifican juntos?
¿Comparten lifecycle?
¿El crecimiento está acotado?
¿Se necesita atomicidad?
¿La duplicación tiene una política clara?Un mismo dominio puede combinar ambas estrategias. De hecho, los modelos más sólidos suelen hacerlo.
MongoDB permite representar relaciones de varias maneras. Esa flexibilidad es útil, pero también permite diseños extremos:
$lookup para reparar un boundary inadecuado;La decisión debe explicar por qué una estructura sirve las operaciones reales y qué costes acepta.
dominio
↓
access patterns
↓
ownership y lifecycle
↓
cardinalidad y crecimiento
↓
atomicidad y consistencia
↓
embedding, reference o combinaciónNo se decide observando únicamente el diagrama de entidades. Dos relaciones one-to-many pueden necesitar modelos distintos porque sus lecturas, cambios y crecimiento son diferentes.
parent
└── related dataAporta:
Introduce:
parent.relatedId
↓
related documentAporta:
Introduce:
$lookup o queries adicionales;Pregunta quién posee realmente el dato.
Un orderItem pertenece a una orden. No se administra fuera de ella. Embedding suele ser natural.
Un product existe aunque no aparezca en una orden. Tiene comandos y lifecycle propios. Referencing suele ser más apropiado.
Ownership no significa solamente “A tiene B” en un diagrama. Significa quién crea, cambia, elimina y gobierna el dato.
Si dos piezas se leen juntas en casi todos los hot paths, embedding puede reducir composición.
Ejemplo:
mostrar orden
→ customer snapshot
→ items
→ total
→ delivery addressSeparar cada parte obligaría a múltiples consultas sin aportar independencia.
Pero que una pantalla muestre dos datos juntos no basta. El backend puede componer información independiente sin convertirla en un mismo aggregate.
Si los datos deben cambiar como una unidad atómica, embeberlos puede simplificar la garantía.
db.orders.updateOne(
{ _id: orderId, status: 'draft' },
{
$push: { items: newItem },
$inc: { totalInCents: newItemTotal }
}
);Cuando los cambios pertenecen a documentos diferentes, las opciones son:
No conviene introducir una transacción solo para conservar un diseño trasladado mecánicamente desde SQL.
Puede embeberse si existe ownership y acceso conjunto. Puede referenciarse si ambas partes tienen lifecycle, permisos o tamaño independientes.
Embedding suele funcionar cuando existe un límite real.
Ejemplo: hasta cinco contactos de emergencia.
Depende del crecimiento. Las líneas de una orden pueden ser acotadas; las reviews de un producto no.
Las relaciones grandes y dinámicas suelen beneficiarse de documentos de asociación referenciados.
{
userId,
organizationId,
role,
joinedAt
}Pregunta cómo será el documento después de años, no solo al crearlo.
10 elementos hoy
→ 1.000 en un año
→ 100.000 en un tenant outlierUn array sin límite conocido es una señal fuerte para separar, aplicar buckets o conservar solo un subset.
También importa la frecuencia de cambio. Un array pequeño actualizado miles de veces por segundo puede ser más problemático que uno mayor pero casi inmutable.
Este criterio evita mucha confusión.
Representa lo que ocurrió en un momento.
{
productId,
name: 'Café molido',
unitPrice: Decimal128('18900.00')
}Si el producto cambia, la orden histórica no debe hacerlo.
Debe reflejar el valor vigente.
product.currentPrice
customer.currentNamePuede mantenerse referenciado o duplicarse con una estrategia de propagación y reconciliación.
Una misma estructura puede contener ambos:
{
productId,
productNameAtPurchase,
unitPriceAtPurchase
}Duplicar un dato casi inmutable puede ser barato. Duplicar un valor que cambia constantemente en millones de documentos puede crear fan-out operativo.
Ejemplo:
category.name cambia rara vez
→ duplicación parcial podría ser viable
inventory.stock cambia continuamente
→ no debe copiarse en cada documento consumidorPregunta qué inconsistencias son aceptables y durante cuánto tiempo.
La estrategia depende de la garantía, no de una preferencia estética.
Embedding puede hacer autosuficiente el documento, pero también aumentar tamaño y transferencia.
Si una query necesita solo tres campos de un documento de varios megabytes, la proyección reduce payload, aunque el diseño del documento y el coste interno siguen importando.
Separar datos grandes que se usan raramente puede mejorar el hot path. Por ejemplo, un perfil básico y un historial extenso pueden tener boundaries distintos.
Embedding de arrays crea multikey indexes. Esto afecta:
Referencing permite índices independientes sobre la colección relacionada, pero añade una consulta o join.
La decisión debe diseñarse junto con query shapes e índices.
En un cluster sharded, el document boundary y la shard key deben analizarse juntos.
Embedding conserva datos dentro de la misma unidad y el mismo shard. Referencing puede conectar documentos distribuidos en shards distintos.
Esto no significa que deba embeberse todo para “evitar red”. Un documento hotspot o una shard key deficiente puede ser peor. Evalúa:
$lookup entre colecciones sharded según soporte actual.Un modelo optimizado para operaciones no tiene que resolver cualquier reporte de forma perfecta.
Embeber snapshots puede facilitar auditoría histórica. Referenciar current state puede facilitar administración central. Para analytics complejos pueden utilizarse pipelines, colecciones derivadas, exports o sistemas especializados.
No sacrifiques el hot path por reportes poco frecuentes sin evaluar alternativas.
productId.// orders
{
_id: orderId,
businessId,
items: [
{
productId,
name: 'Café molido',
quantity: 2,
unitPrice: Decimal128('18900.00')
}
],
total: Decimal128('37800.00')
}
// products
{
_id: productId,
businessId,
name: 'Café premium',
currentPrice: Decimal128('19900.00'),
stock: 40
}productId referencia la entidad actual.name y unitPrice son snapshots.items tiene crecimiento acotado por reglas de una orden.// posts
{
_id: postId,
commentCount: 12840,
recentComments: [
{ commentId, authorName, text, createdAt }
]
}
// comments
{
_id: commentId,
postId,
authorId,
text,
status: 'visible',
createdAt
}La colección comments conserva la relación completa. recentComments es un subset derivado y commentCount un computed value. Debe definirse cómo se actualizan y reconcilian.
| Criterio | Favorece embedding | Favorece referencing |
|---|---|---|
| Ownership | Dependiente del padre | Entidad independiente |
| Cardinalidad | Acotada | Alta o ilimitada |
| Lectura | Siempre juntos | Consultas separadas |
| Actualización | Como una unidad | Ciclos distintos |
| Historia | Snapshot | Current state central |
| Crecimiento | Controlado | Indefinido |
| Atomicidad | Single-document | Coordinación o eventual |
La tabla orienta; no sustituye analizar el workload completo.
No limites la elección a dos extremos. Existen opciones intermedias:
Referencia el documento y copia algunos campos frecuentes.
Conserva una parte reciente o popular embebida y el conjunto completo separado.
Guarda resultados derivados para evitar aggregations repetidas.
Agrupa eventos o mediciones en documentos acotados.
Usa el modelo común para la mayoría y una estrategia distinta para casos extremos.
MongoDB no premia una estética documental. Premia modelos que sirven access patterns y crecimiento real.
Separar documentos controla tamaño, pero puede crear joins, N+1 y operaciones distribuidas.
La duplicación puede ser un snapshot o cache deliberado. Lo incorrecto es duplicar sin ownership ni estrategia de actualización.
Las transacciones son útiles, pero añaden coste y no deben esconder un boundary incorrecto.
Los outliers pueden alcanzar límites y crear hotspots. Evalúa percentiles y máximos.
explain() y observabilidad.Embedding y referencing son herramientas complementarias. La mejor decisión hace explícitos lectura, escritura, crecimiento, consistencia y operación. Un buen modelo no busca pureza; busca que los datos representen correctamente el dominio y sirvan el workload con costes conocidos.
order.items y product.stock suelen requerir estrategias distintas?Diseño de schemas.