¿Cómo funcionan los joins en bases de documentos?

Una consulta relacional en una base de documentos es un join hecho con referencias y lookups en vez de claves foráneas — o evitado al embeber. Ese “o” es todo el tema: las bases de documentos te dan tres maneras de relacionar datos, y la decisión de diseño es cuándo ocurre el join — al escribir (embeber), al consultar en el servidor (lookup), o al consultar en la aplicación (referencias más un fetch de seguimiento).

Puntos clave

Las tres maneras de relacionar documentos

// 1 · Embeber — el "join" ocurrió al momento de escribir
{ _id: 1, title: "Dune", author: { name: "Frank Herbert", born: 1920 } }

// 2 · Referencia + $lookup — el join ocurre al consultar, server-side
db.books.aggregate([
  { $lookup: { from: "authors", localField: "authorId",
               foreignField: "_id", as: "author" } },  // left outer join → array
  { $unwind: "$author" }                               // aplanar → inner join
])

// 3 · Referencia + join en la aplicación — la vía del ODM/SDK (abajo)

La tercera ruta es donde vive la mayoría del código de aplicación — referencias tipadas recorridas con eager loading en una sola solicitud, para que los documentos relacionados lleguen juntos sin un pipeline:

// JavaScript / Node.js — Back4app JS SDK
// A join in a document database: Pointer + include, one request
const query = new Parse.Query('Comment');
query.equalTo('post', postPointer);   // Comment.post is a Pointer<Post>
query.include('author');              // "join" the author document in
const comments = await query.find();

const name = comments[0].get('author').get('username'); // already loaded — no N+1

// Flutter / Dart — Back4app Flutter SDK
// A join in a document database: Pointer + include, one request
final query = QueryBuilder<ParseObject>(ParseObject('Comment'))
  ..whereEqualTo('post', postPointer)
  ..includeObject(['author']); // "join" the author document in
final response = await query.query();

final author = (response.results!.first as ParseObject)
    .get<ParseObject>('author'); // already loaded — no N+1

// iOS / Swift — Back4app Swift SDK
// A join in a document database: Pointer + include, one request
let query = Comment.query("post" == postPointer)
  .include("author") // "join" the author document in
query.find { result in
  if case .success(let comments) = result {
    print(comments.first?.author?.username ?? "") // already loaded — no N+1
  }
}

// Android / Kotlin — Back4app Android SDK
// A join in a document database: Pointer + include, one request
val query = ParseQuery.getQuery<ParseObject>("Comment")
query.whereEqualTo("post", postPointer)
query.include("author") // "join" the author document in
query.findInBackground { comments, e ->
  if (e == null) {
    val name = comments[0].getParseObject("author")?.getString("username")
    Log.d("Comments", "by $name") // already loaded — no N+1
  }
}

Embeber vs. referenciar: la decisión

Los niveles de cardinalidad dan la misma tabla como reglas rápidas: uno-a-pocos embebe el array, uno-a-muchos referencia por ID, uno-a-enormes invierte la dirección — el hijo guarda la referencia al padre, porque ningún documento padre puede sostener un array que crece sin parar. Lo que apunta a los dos anti-patrones detrás de la mayoría de los incidentes de modelado de documentos: los arrays sin límite y el tope de 16MB por documento que eventualmente amenazan. Los arreglos estándar — referenciar en su lugar, embeber un subconjunto acotado (los N más nuevos con una colección de desborde), o agrupar los hijos en documentos-bucket — son todos versiones de “detén el crecimiento del documento”.

El lookup, honestamente

$lookup es un join real con dos asteriscos honestos. La forma: devuelve las coincidencias como un array embebido por documento de entrada — $unwind lo aplana a filas y, sin la semántica de preservar vacíos, convierte el left join en comportamiento de inner join. La performance: los motores de documentos solo ejecutan joins de nested loop, y los benchmarks públicos son directos — hacer join sobre un millón de documentos tomó decenas de segundos con índices, contra medio segundo del equivalente embebido. Las reglas operativas que se desprenden: indexa siempre el campo foráneo (sin índice, cada documento de entrada dispara un escaneo de colección), usa lookups para joins por solicitud sobre un puñado de documentos, y nunca construyas fan-outs de analítica sobre ellos — esa carga pertenece a un warehouse o a un motor relacional.

El problema N+1 y sus cuatro salidas

El bug clásico: una consulta para N padres, y luego un loop que emite una query por padre para sus hijos — N+1 idas a la base que escalan con el tamaño de la página. Las salidas, de mejor a peor: batch — junta los IDs de los padres y trae todos los hijos en una sola query de contenido-en (el populate de los buenos ODMs lo hace por ti); include — eager loading a nivel del SDK que devuelve los documentos referenciados en la misma solicitud, como en las pestañas de arriba; lookup — un solo pipeline server-side; embeber — el join deja de existir. Lo que convierte el N+1 de bug en arquitectura es no notarlo: sale rápido con diez registros de prueba y se derrite con mil — la patología completa tiene su propia entrada en el registro de este glosario.

Casos de uso comunes

• Contenido con autoría. Posts, comentarios, autores — referencias con includes para las vistas de lista, embebidos para los campos snapshot de solo lectura.
• Catálogos y pedidos. La referencia extendida canónica: un pedido embebe el nombre y el precio del producto tal como se vendió (snapshot inmutable) más una referencia al producto vivo.
• Streams de actividad y eventos. Uno-a-enormes — documentos hijos con referencias al padre, nunca arrays en el padre.
• Perfiles de usuario. La vitrina del embebido: direcciones, preferencias, configuraciones — se leen juntas, acotadas, con dueño.
• Grafos sociales. Arrays de referencias muchos-a-muchos — y la señal honesta de que, pasado un punto, esta forma pide un motor relacional o de grafos.

¿Embeber, referenciar o cambiar de motor? Matriz de decisión

La tercera columna es la sección que las páginas de proveedores no van a escribir: si cada pantalla necesita tres lookups y la integridad referencial te quita el sueño, los datos están pidiendo tablas — los modelos de documentos ganan cuando los patrones de acceso son conocidos y jerárquicos, no como reemplazo universal.

Limitaciones y trade-offs

• La desnormalización es un instrumento de deuda. Los campos duplicados matan joins pero deben pagarse al actualizar — el fan-out de escrituras, las ventanas de datos viejos y el código de consistencia (transacciones o triggers de change streams) son los intereses.
• Sin claves foráneas, sin red de seguridad. Las referencias no garantizan existencia; borrar un autor deja referencias huérfanas en los libros, en silencio, a menos que tu plataforma o tu código las limpien.
• Los lookups no se optimizan. Sin reordenamiento de joins, sin estrategias hash — el orden del pipeline es tu plan de consulta.
• Las migraciones entre formas son proyectos reales. Pasar de embebido a referenciado (el rescate del array que crece) significa hacer backfill de colecciones y reescribir queries — modela para la cardinalidad de mañana, no la de hoy.
• El tope de 16MB es un precipicio, no una advertencia. Los patrones de crecimiento que se le acercan degradan la performance mucho antes de tocarlo.

Las consultas relacionales en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Su base de datos de documentos habla un vocabulario relacional por diseño: los Pointers declaran aristas uno-a-muchos, las Relations manejan el muchos-a-muchos, e include() recorre las aristas en una sola solicitud — la salida del N+1 integrada en el SDK, como muestran las pestañas de código de arriba. La API GraphQL generada automáticamente anida objetos relacionados en una sola query sin costo extra, y los borrados pueden ponerse en cascada con triggers de Cloud Code — la red de seguridad de integridad referencial que los motores de documentos dejan fuera.