Unterstützt DynamoDB Foreign Keys?

Nein. DynamoDB hat keine Foreign Keys, keine Constraints für referenzielle Integrität und keine kaskadierenden Deletes — als NoSQL-Datenbank erzwingt es nie Beziehungen zwischen Items oder Tabellen. Stattdessen modellierst du Beziehungen selbst: Denormalisiere verwandte Daten in ein Item oder lege verwandte Items unter einem gemeinsamen Partition Key mit Single-Table-Design zusammen. Um diese modellierten Beziehungen zu sehen und zu durchlaufen, zeichnen die Smart Tables von DynoTable eine Beziehung zwischen zwei Tabellen auf einer Leinwand und durchsuchen die verbundenen Zeilen.

Warum es keine Foreign Keys gibt

Ein Foreign Key existiert, um Joins zu ermöglichen und Integrität über normalisierte Tabellen hinweg zu erzwingen. DynamoDB lässt den JOIN-Operator bewusst weg (AWS empfiehlt stattdessen Denormalisierung) — ein Foreign-Key-Constraint würde also eine Beziehung überwachen, die das Abfragemodell nie ausnutzt. Nichts hindert dich daran, den Key eines anderen Items als Attribut zu speichern — DynamoDB validiert oder kaskadiert ihn nur nicht.

Wie Beziehungen stattdessen modelliert werden

Einbetten — kleine, begrenzte Kinddaten leben als Liste oder Map innerhalb des Eltern-Items.
Zusammenlegen — Eltern und Kinder teilen sich einen Partition Key mit unterschiedlichen Sort Keys, sodass eine Query die ganze Beziehung zurückgibt; das ist das Herz von Single-Table-Design.
Duplizieren — kopiere die Felder, die jedes Zugriffsmuster braucht, auf die Items, die sie brauchen, und nimm Pflegeaufwand beim Schreiben für Lesevorgänge mit einer einzigen Anfrage in Kauf.

Die Leitfäden zu 1:n und n:m behandeln jede Form ausführlich.

Integrität erzwingen, wenn es darauf ankommt

Für die Fälle, in denen du dich auf ein Constraint gestützt hättest, gibt dir DynamoDB Bausteine: Condition Expressions sichern einen Write über den Zustand des geschriebenen Items ab, und der ConditionCheck einer Transaktion kann prüfen, ob ein anderes Item (etwa das Eltern-Item) in derselben Alles-oder-nichts-Operation existiert. Kaskadierende Deletes werden zu expliziter Anwendungslogik oder zu einer Streams-getriebenen Aufräumroutine.

Wie das aussieht, wenn du es ausführst

Wir haben ein PROFILE-Item und zwei ORDER#-Items unter pk = "CUSTOMER#1" abgelegt, das Profil gelöscht und die Partition erneut abgefragt:

Count: 2
[{"sk":{"S":"ORDER#1"},"pk":{"S":"CUSTOMER#1"}},
 {"sk":{"S":"ORDER#2"},"pk":{"S":"CUSTOMER#1"}}]

Das Delete meldete Erfolg. Zwei Waisen, keine Warnung, kein Fehler zum Abfangen. In PostgreSQL schlägt dasselbe Delete fehl, kaskadiert oder setzt die Kindreferenz auf null — je nachdem, welches Constraint du deklariert hast.

Dann der nächstbeste Ersatz: ein TransactWriteItems, das das Eltern-Item prüft, bevor es eine dritte Bestellung schreibt.

TransactionCanceledException: Transaction cancelled, please refer cancellation
reasons for specific reasons [ConditionalCheckFailed, None]

CancellationReasons: [
  {"Code":"ConditionalCheckFailed","Message":"The conditional request failed."},
  {"Code":"None"}
]

Die Array-Positionen entsprechen deinen TransactItems-Positionen — [ConditionalCheckFailed, None] sagt also, dass Aktion 0 (die Elternprüfung) fehlschlug und Aktion 1 (der Kind-Write) in Ordnung war. Mit einem Guard liest sich das klar; mit acht Aktionen ist dieses Array der einzige Weg herauszufinden, welche gescheitert ist.

Es wird auch abgerechnet. Ein transaktionaler Write verbraucht zwei Write-Einheiten pro Item, und AWS sagt ausdrücklich, dass "this capacity is consumed even when the transaction is canceled". Jeder abgelehnte Write kostet dasselbe wie ein angenommener.

Tiefer einsteigen

Fang mit Single-Table-Design an, bau die absichernden Bedingungen im Expression Builder und lade DynoTable herunter, um diese Beziehungen visuell zu durchsuchen — seine Smart Tables verbinden Eltern- und Kindtabellen auf einer Leinwand, sodass du die ganze Item Collection in einer Ansicht siehst.

Referenzen

Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation.

Die Abfrage der verwaisten Kinder und die Cancellation-Ausgabe wurden am 2026-07-28 gegen DynamoDB Local 3.3.0 mit @aws-sdk/client-dynamodb 3.1095.0 auf Node v24.18.0 reproduziert.