3.1. Modelo relacional × modelo de documentos
Documento brilha em dados em árvore lidos juntos; relacional brilha em joins e relações muitos-para-muitos.
Resumo
- Descompasso objeto-relacional: objetos aninhados × tabelas planas. ORMs ajudam, mas escondem consultas ruins.
- Documento (JSON): boa localidade, esquema flexível; ideal para estrutura em árvore carregada inteira.
- Normalizar: guardar o fato uma vez e referenciar por ID. Desnormalizar: duplicar para ler rápido e escrever com cuidado.
- Relações muitos-para-muitos pedem joins; documentos lidam mal com elas.
- Schema-on-read (documento) × schema-on-write (relacional). Estrela/floco de neve: fatos + dimensões em análise.
Perguntas-chave
responda de cabeça, depois abraO que é localidade no modelo de documentos?
Tudo o que é lido junto fica guardado junto; uma única leitura traz o documento inteiro, sem joins.
Quando desnormalizar vale a pena?
Quando leituras são muito mais frequentes que escritas e o custo de manter as cópias consistentes é aceitável.
O que é um esquema estrela?
Uma tabela de fatos grande (cada evento, como uma venda) ligada a tabelas de dimensão (quem, o quê, onde, quando).
Exercícios de fixação
0/5 respondidas1.
Um app guarda perfis com lista de cargos e formações, sempre exibidos inteiros numa única tela. Qual modelo encaixa melhor?
2.
Agora o app precisa listar todas as pessoas que trabalharam numa empresa e mudar o nome da empresa em todo lugar. O que pesa contra documentos?
3.
Guardar
cidade_id em vez do texto "São Paulo" em cada registro é:4.
Um banco aceita qualquer JSON e o código da aplicação interpreta a estrutura ao ler. Isso é:
5.
No warehouse, a tabela
vendas tem uma linha por venda com chaves para produto, loja e data. Ela é a: