MongoDB
Explica cómo relacionar documentos mediante identificadores cuando las entidades tienen ciclos de vida independientes, cardinalidad alta o crecimiento no acotado.
significa guardar el identificador de otro documento en lugar de copiar toda su información dentro del documento actual.
{
_id: ObjectId('...'),
customerId: ObjectId('...'),
status: 'pending',
total: Decimal128('37800.00')
}La orden conoce el identificador del cliente, pero el cliente vive como documento independiente:
orders.customerId
↓
customers._idUna referencia en MongoDB es solo un valor con significado acordado por la aplicación. No crea automáticamente una foreign key, no comprueba que el destino exista y no ejecuta cascades cuando se elimina el documento relacionado.
Referencing evita que una entidad independiente deba copiarse completa dentro de cada documento que la utiliza. Es especialmente útil cuando:
Ejemplo: un producto existe aunque ninguna orden lo haya vendido todavía. Tiene stock, categoría, precio actual, imágenes y reglas propias. Por eso el producto suele mantenerse independiente, aunque una orden embeberá algunos de sus valores como snapshot.
entidad A
└── relatedId
↓
entidad B independienteLa relación se reconstruye mediante una de estas estrategias:
$in;$lookup en aggregation;La elección depende de frecuencia, volumen, latencia y consistencia.
La forma más común es guardar directamente _id del documento relacionado:
{
_id: ObjectId('...'),
businessId: ObjectId('...'),
categoryId: ObjectId('...'),
supplierIds: [
ObjectId('...'),
ObjectId('...')
]
}MongoDB no necesita un tipo especial “reference”. Usar ObjectId, UUID o string es una decisión del schema.
DBRefs existen como formato más estructurado, pero las referencias manuales suelen ser más simples y explícitas para aplicaciones modernas.
Una entidad es independiente cuando posee varias de estas características:
Un customer, product o business normalmente cumple varias. Un orderItem suele no cumplirlas y puede embeberse.
Supón un producto con millones de reviews.
Modelo riesgoso:
{
_id: productId,
reviews: [/* crecimiento indefinido */]
}Modelo referenciado:
// products
{ _id: productId, name: 'Café molido' }
// reviews
{
_id: ObjectId('...'),
productId,
authorId,
rating: 5,
comment: 'Excelente',
createdAt: ISODate('2026-07-24T12:00:00Z')
}Ahora las reviews pueden paginarse, indexarse y retenerse independientemente:
db.reviews.find({ productId })
.sort({ createdAt: -1, _id: -1 })
.limit(20);Índice candidato:
db.reviews.createIndex({
productId: 1,
createdAt: -1,
_id: -1
});El coste es que leer producto y reviews requiere composición.
En una relación one-to-many normalmente conviene que el lado “many” guarde la referencia al “one”:
// preferred
{
_id: reviewId,
productId
}En cambio, guardar todos los IDs dentro del producto:
{
_id: productId,
reviewIds: [/* crecimiento ilimitado */]
}reintroduce el problema del array ilimitado y exige actualizar el padre cada vez que aparece una review.
Puede mantenerse un subset de IDs recientes si existe un access pattern concreto, pero no debe convertirse en la fuente completa de la relación.
Una relación many-to-many grande y dinámica suele requerir documentos de asociación.
Ejemplo: usuarios y organizaciones.
{
_id: ObjectId('...'),
userId: ObjectId('...'),
organizationId: ObjectId('...'),
role: 'editor',
joinedAt: ISODate('2026-07-24T12:00:00Z')
}Este documento no solo une IDs: representa la membresía y sus atributos. Permite consultar por usuario u organización con índices distintos.
db.memberships.createIndex({ userId: 1, organizationId: 1 }, { unique: true });
db.memberships.createIndex({ organizationId: 1, role: 1 });El índice unique protege duplicados concurrentes de la misma membresía. La referencia por sí sola no lo hace.
Solo un documento guarda el ID del otro.
orders.customerId → customers._idEs más simple y evita mantener dos lados sincronizados.
Ambos documentos guardan información de la relación.
orders.customerId → customers._id
customers.recentOrderIds → orders._idPuede acelerar un access pattern, pero introduce duplicación. Debe existir una política para actualizaciones, fallos y reconciliación.
No guardes ambos lados solo porque en un diagrama la relación “se ve completa”.
MongoDB no impide esto:
{
customerId: ObjectId('ffffffffffffffffffffffff')
}aunque no exista ese cliente.
La integridad puede protegerse con varias capas:
Antes de crear la orden, comprobar que el cliente existe y pertenece al negocio.
Ventaja: mensaje de error claro.
Limitación: una comprobación separada puede sufrir race conditions si el cliente se elimina inmediatamente después.
Cuando varias escrituras deben mantenerse como una unidad, una transacción puede proteger el cambio. No transforma la referencia en foreign key permanente.
En vez de borrar físicamente un cliente referenciado, se puede desactivar o anonimizar según el dominio.
Jobs periódicos pueden detectar dangling references o inconsistencias históricas.
Protegen forma y unicidad local, pero no existencia en otra colección.
Una dangling reference apunta a un documento inexistente.
Puede aparecer por:
Consecuencias:
$lookup devuelve array vacío;La lectura debe manejar ausencia explícitamente:
const customer = await customers.findOne({
_id: order.customerId,
businessId: order.businessId
});
if (!customer) {
// Decide según el dominio: error, placeholder o registro de inconsistencia.
}No utilices non-null assertions para esconder el caso.
MongoDB no ejecuta ON DELETE CASCADE automáticamente.
Antes de eliminar un documento, define:
Ejemplo: eliminar un producto no debería borrar items históricos de órdenes. Esos items son snapshots. En cambio, podría eliminar asociaciones de catálogo que no tienen valor histórico.
Este patrón es ineficiente:
leer 100 órdenes
→ por cada orden, leer un cliente
→ 101 queriesAlternativas:
const customerIds = [...new Set(orders.map(order => order.customerId))];
const customers = await db.customers.find({
_id: { $in: customerIds }
}).toArray();Después se crea un mapa por ID y se compone la respuesta.
db.orders.aggregate([
{ $match: { businessId, status: 'pending' } },
{ $sort: { createdAt: -1, _id: -1 } },
{ $limit: 20 },
{
$lookup: {
from: 'customers',
localField: 'customerId',
foreignField: '_id',
as: 'customer'
}
}
]);Filtrar y limitar antes del $lookup reduce el trabajo cuando la semántica lo permite. El campo extranjero debe tener un índice compatible.
Guardar customer.name como snapshot o display value puede evitar el join para el hot path.
$lookup combina documentos, pero no vuelve relacional el modelo ni elimina el coste de consultar ambas colecciones.
Evalúa:
Un $lookup ocasional puede ser correcto. Utilizarlo en cada request para reconstruir aggregates que siempre se leen juntos puede indicar un boundary deficiente.
Referencing y duplicación pueden coexistir:
{
customer: {
id: ObjectId('...'),
nameAtPurchase: 'Laura Gómez'
}
}El ID conecta con el cliente actual. El nombre conserva historia. Esta estrategia debe documentar qué campos son snapshots y cuáles se consideran current state.
Dos clientes pueden crear una asociación igual al mismo tiempo. Una comprobación previa no evita por sí sola duplicados:
request A comprueba → no existe
request B comprueba → no existe
A inserta
B insertaLa protección real utiliza un índice unique:
db.memberships.createIndex(
{ userId: 1, organizationId: 1 },
{ unique: true }
);La aplicación debe capturar duplicate key y convertirlo en un resultado de dominio adecuado.
En un sharded cluster, las referencias pueden apuntar a documentos de otros shards. MongoDB no garantiza colocación conjunta por el simple hecho de compartir IDs.
El diseño debe considerar:
$lookup soportado por la versión y topología;Una referencia frecuente entre colecciones con shard keys incompatibles puede elevar el coste operacional.
Es una opción fuerte cuando:
Referencing puede ser una mala decisión cuando:
No existe comprobación automática de existencia ni cascade.
Produce colecciones fragmentadas y $lookup constante.
Sigue siendo crecimiento ilimitado, aunque los elementos sean pequeños.
Genera N+1, latencia y presión sobre el pool.
Las relaciones bidireccionales se desincronizan durante fallos.
Mongoose puede ocultar queries adicionales. La abstracción no elimina cardinalidad, red ni índices.
$lookup.Referencing preserva independencia y controla crecimiento, pero traslada al diseño la responsabilidad de composición, integridad, cascades y consistencia. Una referencia no es una garantía: es una conexión lógica que debe protegerse mediante casos de uso, índices, políticas y observabilidad.
customerId no garantiza que exista un cliente?productId como nombre y precio embebidos?Embedding frente a referencing.