Como funcionam joins em bancos de documentos?

Uma consulta relacional em banco de documentos é um join feito com referências e lookups em vez de chaves estrangeiras — ou evitado ao embutir os dados. Esse “ou” é o assunto inteiro: bancos de documentos dão três formas de relacionar dados, e a decisão de design é quando o join acontece — na escrita (embutir), na consulta dentro do servidor (lookup), ou na consulta dentro da aplicação (referências mais uma busca de acompanhamento).

Principais pontos

As três formas de relacionar documentos

// 1 · Embutir — o "join" aconteceu na hora da escrita
{ _id: 1, title: "Dune", author: { name: "Frank Herbert", born: 1920 } }

// 2 · Referência + $lookup — o join acontece na consulta, no servidor
db.books.aggregate([
  { $lookup: { from: "authors", localField: "authorId",
               foreignField: "_id", as: "author" } },  // left outer join → array
  { $unwind: "$author" }                               // achata → inner join
])

// 3 · Referência + join no lado da aplicação — o caminho de ODM/SDK (abaixo)

O terceiro caminho é onde vive a maior parte do código de aplicação — referências tipadas percorridas de forma eager em uma requisição, para os documentos relacionados chegarem juntos sem 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
  }
}

Embutir vs. referenciar: a decisão

Os degraus de cardinalidade dão a mesma tabela em forma de regra de bolso: um-para-poucos embute o array, um-para-muitos referencia por ID, um-para-enormes inverte a direção — o filho guarda a referência ao pai, porque nenhum documento pai pode segurar um array que só cresce. O que aponta para os dois antipadrões por trás da maioria dos incidentes de modelagem de documentos: arrays sem limite e o teto de 16MB por documento que eles acabam ameaçando. As correções padrão — referenciar, embutir um subconjunto limitado (os N mais recentes com uma coleção de excedente), ou agrupar filhos em documentos-balde — são todas versões de “pare o documento de crescer”.

O lookup, honestamente

O $lookup é um join de verdade com dois asteriscos honestos. Formato: ele retorna os casamentos como um array embutido por documento de entrada — $unwind o achata em linhas e, sem a semântica de preservar vazios, converte o left join em comportamento de inner join. Performance: motores de documentos só executam joins de loop aninhado, e os benchmarks públicos são diretos — juntar um milhão de documentos levou dezenas de segundos com índices, contra meio segundo do equivalente embutido. As regras operacionais que seguem daí: sempre indexe o campo estrangeiro (sem ele, cada documento de entrada dispara uma varredura da coleção), use lookups para joins por requisição sobre um punhado de documentos, e nunca construa fan-outs analíticos sobre eles — essa carga pertence a um warehouse ou a um motor relacional.

O problema N+1 e suas quatro saídas

O bug clássico: uma query para N pais, depois um loop disparando uma query por pai para os filhos — N+1 idas ao banco que escalam com o tamanho da página. As saídas, da melhor para as demais: batch — colete os IDs dos pais e busque todos os filhos numa query de contido-em (o populate dos bons ODMs faz isso por você); include — eager loading no nível do SDK, que retorna os documentos referenciados na mesma requisição, como nas abas acima; lookup — um pipeline no servidor; embutir — o join deixa de existir. O que transforma N+1 de bug em arquitetura é não notá-lo: ele entrega rápido com dez registros de teste e derrete com mil — a patologia completa tem verbete próprio no registro deste glossário.

Casos de uso comuns

• Conteúdo com autoria. Posts, comentários, autores — referências com includes para as listas, embeds para os campos de snapshot só de exibição.
• Catálogos e pedidos. A referência estendida canônica: um pedido embute o nome e o preço do produto como vendidos (snapshot imutável) mais uma referência ao produto vivo.
• Fluxos de atividade e eventos. Um-para-enormes — documentos filhos guardando referências ao pai, nunca arrays no pai.
• Perfis de usuário. A vitrine do embutir: endereços, preferências, configurações — lidos juntos, limitados, de um dono só.
• Grafos sociais. Arrays de referências muitos-para-muitos — e o sinal honesto de que, passado um ponto, esse formato quer um motor relacional ou de grafos.

Embutir, referenciar ou trocar de motor? Matriz de decisão

A terceira coluna é a seção que páginas de fornecedor não escrevem: se toda tela precisa de três lookups e a integridade referencial tira o seu sono, os dados estão pedindo tabelas — modelos de documentos ganham quando os padrões de acesso são conhecidos e hierárquicos, não como substituto universal.

Limitações e trade-offs

• Denormalização é um instrumento de dívida. Campos duplicados matam joins mas precisam ser quitados no update — escritas em fan-out, janelas de dados velhos e código de consistência (transações ou triggers de change stream) são os juros.
• Sem chaves estrangeiras, sem rede de proteção. Referências não garantem existência; deletar um autor deixa referências de livros órfãs em silêncio, a menos que a plataforma ou o seu código limpe.
• Lookups não otimizam. Sem reordenação de joins, sem estratégias de hash — a ordem do pipeline é o seu plano de query.
• Migrações entre formatos são projetos de verdade. De embutido para referenciado (o resgate do array que cresceu) significa fazer backfill de coleções e reescrever queries — modele para a cardinalidade de amanhã, não a de hoje.
• O teto de 16MB é um penhasco, não um aviso. Padrões de crescimento que se aproximam dele degradam a performance muito antes do impacto.

Consultas relacionais no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. Seu banco de documentos fala um vocabulário relacional por design: Pointers declaram arestas um-para-muitos, Relations resolvem muitos-para-muitos, e include() percorre as arestas numa única requisição — a saída do N+1 embutida no SDK, como as abas de código acima mostram. A API GraphQL gerada automaticamente aninha objetos relacionados em uma query de graça, e deletes podem cascatear por triggers de Cloud Code — a rede de proteção de integridade referencial que motores de documentos deixam de fora.