Modelagem de dados

É aqui que o DynamoDB mais se afasta do SQL. Você não normaliza em uma tabela por entidade — você parte dos seus padrões de acesso e desenha chaves que os atendem, muitas vezes empacotando todas as entidades em uma única tabela. Feito do jeito certo, você busca um pai e seus filhos em uma única Query, sem joins.

Feito do jeito errado, você acaba com uma tabela que não consegue consultar e uma migração que não consegue executar. Então os trade-offs importam, e esta seção é honesta sobre os casos em que o single-table design é a escolha errada.

0 de 7 lidosQuiz

Tabela Única no DynamoDB

Tabela única no DynamoDB — por que uma tabela com chaves sobrecarregadas vence uma tabela por entidade, com um exemplo concreto de pedido/cliente e o padrão de sobrecarga de GSI.

Intermediário4 min de leitura

Como Modelar Dados no DynamoDB

Como modelar dados no DynamoDB do jeito orientado a padrões de acesso — um passo a passo que transforma as consultas de um placar multiplayer em chaves de partição e de ordenação.

Intermediário8 min de leitura

Quando NÃO Usar Single-Table Design no DynamoDB

Quando NÃO usar single-table design no DynamoDB — as cargas de trabalho onde múltiplas tabelas vencem (analytics pesado, CRUD simples, escalonamento independente), com exemplos concretos.

Intermediário6 min de leitura

O Atributo Type no DynamoDB

O atributo Type no DynamoDB — por que você carimba um tipo de entidade em cada item para identificar registros, filtrar uma GSI para uma única entidade e sobreviver a migrações futuras.