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

Single-Table Design dans DynamoDB

Le single-table design dans DynamoDB — pourquoi une table aux clés surchargées bat une table par entité, avec un exemple concret commande/client et le pattern de surcharge de GSI.

Intermédiaire4 min de lecture

Comment modéliser des données dans DynamoDB

Comment modéliser les données dans DynamoDB en partant des motifs d'accès — un parcours pas à pas qui transforme les requêtes d'un classement multijoueur en clés de partition et de tri.

Intermédiaire8 min de lecture

Quand NE PAS utiliser le single-table design dans DynamoDB

Quand NE PAS utiliser le single-table design dans DynamoDB — les charges où plusieurs tables l'emportent (analytique lourde, CRUD simple, scaling indépendant), avec des exemples concrets.

Intermédiaire6 min de lecture

L'attribut Type dans DynamoDB

L'attribut Type de DynamoDB — pourquoi tu estampilles un type d'entité sur chaque item pour identifier les enregistrements, filtrer un GSI sur une seule entité et survivre aux migrations futures.