MongoDB: Como mudar seu jeito relacional de pensar, parte 2

Se você vem do mundo relacional, a maior dificuldade com MongoDB não é a sintaxe. É mudar a forma de pensar sobre dados. Nesta segunda parte, vamos além do básico.

Recapitulando

No modelo relacional, você normaliza tudo. Separa dados em tabelas, cria chaves estrangeiras, faz JOINs. No MongoDB, a ideia é diferente: você modela os dados de acordo com como eles serão consumidos.

Embedding vs Referencing

No MongoDB, existem duas formas principais de relacionar dados:

Embedding (subdocumentos)

Você coloca os dados relacionados dentro do próprio documento:

{
  "nome": "Laura",
  "enderecos": [
    { "rua": "Rua das Flores", "cidade": "São Paulo" },
    { "rua": "Av. Brasil", "cidade": "Rio de Janeiro" }
  ]
}

Use embedding quando:

• Os dados são acessados juntos
• A relação é de um pra poucos
• Os subdocumentos não crescem indefinidamente

Referencing (referências)

Você guarda apenas o ID do documento relacionado:

// Coleção: usuarios
{ "_id": ObjectId("abc123"), "nome": "Laura" }

// Coleção: pedidos
{ "usuario_id": ObjectId("abc123"), "produto": "Notebook", "valor": 3500 }

Use referências quando:

• Os dados relacionados são muitos
• Precisam ser acessados independentemente
• Crescem de forma imprevisível

Pare de pensar em tabelas

No relacional, você pergunta: “como eu normalizo isso?”. No MongoDB, a pergunta certa é: “como minha aplicação vai ler esses dados?”.

Se uma tela mostra o usuário com seus endereços, faz sentido ter tudo num documento só. Se outra tela lista todos os pedidos independente do usuário, faz sentido separar.

Desnormalização é intencional

No relacional, duplicar dados é pecado. No MongoDB, é estratégia. Você duplica quando isso melhora a performance de leitura. A troca é: leituras rápidas por escritas um pouco mais complexas.

Cuidados

• Documentos têm limite de 16MB — não coloque listas que podem crescer sem limite dentro de um documento
• Atualizações em subdocumentos podem ser mais complexas do que em documentos separados
• Não existe JOIN nativo — se você precisa de JOINs o tempo todo, talvez o modelo precise ser repensado

Mudar o jeito relacional de pensar leva tempo. O segredo é sempre partir de como a aplicação consome os dados, não de como eles se relacionam em teoria.