Modélisation de données

C’est là que DynamoDB s’écarte le plus de SQL. Tu ne normalises pas en une table par entité — tu pars de tes modes d’accès et tu conçois des clés qui les servent, en empaquetant souvent chaque entité dans une seule table. Bien fait, tu récupères un parent et ses enfants en un seul Query, sans jointures.

Mal fait, tu te retrouves avec une table que tu ne peux pas requêter et une migration que tu ne peux pas exécuter. Les compromis comptent donc, et cette section est honnête sur les cas où le single-table design est le mauvais choix.

0 sur 7 lusQuiz

Commence par le single-table design — tout ce qui suit suppose ce modèle mental.

Esquisse le schéma avant de le construire avec l’outil de Single-Table Design gratuit — il transforme une liste de patterns d’accès en plan PK/SK/GSI. Puis essaie DynoTable pour modéliser et parcourir ces structures sur une table live — et pour la question ad hoc que tes clés ne servent pas, son SQL Workbench exécute JOIN, GROUP BY et les agrégats côté client.