Estrutura para decisões de design de esquemas
Aplique uma lista de verificação estruturada — padrões de consulta, frequência de escrita e crescimento dos documentos — para escolher entre incorporação e referências em qualquer domínio.
Estrutura para decisões de design de esquemas é uma aula grátis de MongoDB Academy no CoddyKit. Esta é a aula 4 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de MongoDB Academy, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de MongoDB Academy inclui 4 aulas no total.
Por que uma estrutura de decisão é importante
A flexibilidade dos esquemas do MongoDB é poderosa, mas pode levar à paralisia por análise. Você deve incorporar ou usar referências? Quando a escolha não é óbvia? Uma estrutura de decisão organizada substitui as suposições por uma lista de verificação reproduzível. Ao fazer as mesmas perguntas sobre padrões de consulta, frequência de gravação e crescimento dos documentos, você pode chegar ao esquema adequado para qualquer domínio, de forma consistente.
Etapa 1: identifique os padrões de consulta
Comece listando as consultas de leitura mais frequentes que sua aplicação realiza. Pergunte: essas consultas sempre precisam do pai e dos filhos juntos ou os filhos são consultados de forma independente? Se os dados filhos quase sempre forem buscados com o pai, a incorporação elimina uma viagem de ida e volta. Se os filhos forem consultados, ordenados ou filtrados com frequência por conta própria, as referências mantêm as consultas simples e os índices concentrados.
Etapa 2: estime o tamanho e o crescimento dos dados
Para cada matriz ou estrutura aninhada em potencial, pergunte: quantos elementos ela terá em estado estável e ela pode crescer sem limite? Use regras de negócio aproximadas: um usuário raramente tem mais de 5 endereços (incorpore-os), mas pode escrever milhares de avaliações (use referências). Qualquer elemento com limite superior desconhecido ou sem limite é candidato a uma coleção separada.
Etapa 3: avalie a frequência de gravação
Considere com que frequência os dados filhos são gravados em comparação com o pai. Incorporar significa que cada atualização de um filho regrava o documento pai, acionando uma movimentação no armazenamento se o documento crescer. Se os filhos forem atualizados com muita frequência e de forma independente do pai, o custo de regravar o pai a cada vez favorece o uso de referências — os documentos filhos são atualizados no próprio local, sem tocar no pai.
Etapa 4: verifique se há compartilhamento de dados
Pergunte se os dados filhos são propriedade de um único pai ou compartilhados entre vários pais. Um endereço pertence a um único usuário — é seguro incorporá-lo. Um produto em um catálogo é referenciado por potencialmente milhares de pedidos — ele deve estar em sua própria coleção para evitar duplicação e dados desatualizados. Dados compartilhados devem sempre usar referências, nunca ser incorporados.
Etapa 5: avalie os requisitos de atomicidade
O MongoDB garante gravações atômicas no nível do documento gratuitamente — não são necessárias transações. Se você precisar atualizar um pai e seus filhos atomicamente, a incorporação mantém ambos no mesmo documento, fazendo com que qualquer atualização seja atômica por padrão. Se você usar referências entre duas coleções e precisar de atomicidade, deverá usar uma transação de vários documentos, o que adiciona latência e complexidade.
A tabela de decisão da estrutura
Aplique estas regras na ordem:
- Os elementos filhos são sempre buscados com o elemento pai, têm uma quantidade pequena e pertencem ao pai: EMBED
- Os elementos filhos são consultados de forma independente ou compartilhados: REFERENCE
- Os elementos filhos podem crescer sem limite: REFERENCE (ou padrão de agrupamento)
- É necessária uma atualização atômica entre o pai e os elementos filhos: EMBED (ou transação)
- A frequência de gravação dos elementos filhos é alta em relação à do pai: REFERENCE
Se várias regras entrarem em conflito, usar referências é a opção padrão mais segura.
Exemplo: esquema de pedidos de comércio eletrônico
Aplique a estrutura a um pedido em um sistema de comércio eletrônico. Itens do pedido: sempre buscados com o pedido, quantidade pequena (menos de 50) e pertencentes ao pedido → incorporar. Endereço de entrega: instantâneo no momento do pedido, nunca compartilhado → incorporar. Cliente: compartilhado entre milhares de pedidos → referenciar. Catálogo de produtos: compartilhado entre pedidos e atualizado de forma independente → referenciar.
db.orders.insertOne({
_id: ObjectId(),
customerId: ObjectId('c1'), // reference — shared data
shippingAddress: { // embed — point-in-time snapshot
street: '123 Maple St',
city: 'Austin'
},
items: [ // embed — small, owned by order
{ productId: ObjectId('p1'), qty: 2, price: 19.99, name: 'Widget' }
]
});Exemplo: esquema de redes sociais
Aplique a estrutura a uma publicação em uma rede social. Autor da publicação: compartilhado entre publicações → referenciar. Corpo e metadados da publicação: pertencentes à publicação e pequenos → incorporar. Curtidas (somente a contagem): campo numérico → incorporar como contador. Comentários: potencialmente milhares, consultados e paginados de forma independente → referenciar em uma coleção comments separada.
db.posts.insertOne({
_id: ObjectId(),
authorId: ObjectId('u1'), // reference
title: 'Why MongoDB rocks',
body: '<p>Because documents...</p>',
tags: ['mongodb', 'nosql'], // embed — small, owned
likesCount: 0, // embed — simple counter
createdAt: new Date()
// comments live in db.comments, NOT embedded here
});Evolução do esquema ao longo do tempo
O esquema adequado no lançamento pode não ser o adequado em grande escala. Comece com o design correto mais simples. Se mais tarde você descobrir que uma matriz incorporada está ficando grande demais, migre-a para uma coleção separada. O esquema flexível do MongoDB possibilita uma evolução incremental: você pode gravar novos documentos no novo formato mantendo os antigos e, depois, preencher os dados anteriores com um script de migração.
Documentação das decisões sobre o esquema
Registre o raciocínio por trás de cada escolha de esquema enquanto ele ainda está fresco. Um comentário em um arquivo de esquema do Mongoose ou um breve documento de design explicando por que items são incorporados, mas customerId é referenciado, traz enormes benefícios quando um novo engenheiro entra na equipe ou quando você revisita o esquema seis meses depois. O design do esquema é um ato deliberado, não um acidente.
const orderSchema = new mongoose.Schema({
customerId: { type: mongoose.Schema.Types.ObjectId, ref: 'Customer' }, // reference: shared
shippingAddress: addressSchema, // embed: point-in-time snapshot
items: [lineItemSchema], // embed: small, always with order
status: { type: String, enum: ['pending', 'shipped', 'delivered'] },
createdAt: { type: Date, default: Date.now }
});Verificação rápida
Teste sua compreensão dos conceitos de MongoDB e bancos de dados NoSQL desta lição.
Recapitulação da lição
Nesta lição, você aprendeu que: a estrutura de decisão em cinco etapas abrange padrões de consulta, tamanho dos dados, frequência de gravação, compartilhamento e atomicidade; os dados compartilhados sempre devem estar em uma coleção separada e referenciada; e as decisões sobre o esquema devem ser documentadas junto ao código. A seguir, exploraremos a validação de esquemas com JSON Schema para garantir a qualidade dos dados nas coleções do MongoDB.
Aprenda JavaScript com um tutor de IA — grátis
Escreva e execute código real no seu navegador, obtenha ajuda instantânea de um tutor de IA 24/7 e continue de onde parou na web ou no app.
- Cursos
- 30
- Aulas
- 120
Perguntas Frequentes
A aula “Estrutura para decisões de design de esquemas” é grátis?
Sim — o texto completo de “Estrutura para decisões de design de esquemas” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de MongoDB Academy, atualize para CoddyKit PRO. O curso de MongoDB Academy inclui 4 aulas no total.
O que vou aprender em “Estrutura para decisões de design de esquemas”?
Aplique uma lista de verificação estruturada — padrões de consulta, frequência de escrita e crescimento dos documentos — para escolher entre incorporação e referências em qualquer domínio. Você pratica MongoDB Academy com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.
Preciso ter experiência prévia para começar MongoDB Academy?
Nenhuma experiência prévia é necessária. MongoDB Academy no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 4 de 4.
Quanto tempo leva a aula “Estrutura para decisões de design de esquemas”?
A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.
Posso escrever e executar código nesta aula de MongoDB Academy?
Sim. Cada aula de MongoDB Academy inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.
Todas as aulas deste curso
- Incorporação: relações de um para poucos
- Referências: relações de um para muitos e muitos para muitos
- O antipadrão de matrizes ilimitadas
- Estrutura para decisões de design de esquemas