Datenmodellierung

Hier weicht DynamoDB am stärksten von SQL ab. Du normalisierst nicht in eine Tabelle pro Entität — du startest von deinen Zugriffsmustern und entwirfst Keys, die sie bedienen, oft indem du jede Entität in eine einzige Tabelle packst. Richtig gemacht, holst du einen Parent und seine Children in einer einzigen Query, ganz ohne Joins.

Falsch gemacht, bekommst du eine Tabelle, die du nicht abfragen kannst, und eine Migration, die du nicht ausführen kannst. Die Trade-offs zählen also, und dieser Abschnitt ist ehrlich über die Fälle, in denen Single-Table-Design die falsche Wahl ist.

Starte mit Single-Table-Design — alles danach setzt dieses mentale Modell voraus.

Skizziere das Schema, bevor du es baust, mit dem kostenlosen Single-Table-Design-Tool — es verwandelt eine Liste von Zugriffsmustern in einen PK/SK/GSI-Plan. Dann probier DynoTable aus, um diese Layouts gegen eine echte Tabelle zu modellieren und zu durchstöbern — und für die spontane Frage, die deine Keys nicht bedienen, führt seine SQL Workbench JOIN, GROUP BY und Aggregationen client-seitig aus.