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.
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.