DynamoDB Item-basierte Actions: GetItem, PutItem, UpdateItem, DeleteItem

Die DynamoDB-API teilt sich in drei Familien: Item-basierte Actions, die auf einem einzelnen Item über seinen Primary Key arbeiten, Query, das einen Bereich innerhalb einer Partition liest, und Scan, das alles liest. Dieser Guide ist die erste Familie — die vier Operationen, die du am häufigsten nutzt: GetItem, PutItem, UpdateItem, DeleteItem. Sie sind die billigsten, schnellsten Aufrufe, die DynamoDB bietet, und ihre Unterschiede richtig zu verstehen (besonders Put vs. Update) verhindert eine ganze Klasse von Bugs mit versehentlichem Datenverlust.

Was sind die Item-basierten Operationen von DynamoDB?

DynamoDBs Item-basierte Operationen sind die vier Aufrufe, die über den vollständigen Primary Key auf einem einzelnen Item arbeiten: GetItem liest es, PutItem legt es an oder ersetzt es vollständig, UpdateItem ändert bestimmte Attribute an Ort und Stelle, und DeleteItem entfernt es. Jeder adressiert genau ein Item, was sie zu den schnellsten, billigsten Aufrufen macht — anders als Query und Scan, die viele Items lesen.

GetItem — ein Item über seinen vollständigen Primary Key lesen.
PutItem — ein Item anlegen oder vollständig ersetzen.
UpdateItem — bestimmte Attribute eines Items an Ort und Stelle anlegen oder ändern.
DeleteItem — ein Item über seinen vollständigen Primary Key entfernen.
Alle vier brauchen den vollständigen Primary Key (Partition Key, plus Sort Key, wenn die Tabelle einen hat) — sie adressieren genau ein Item.
PutItem überschreibt das ganze Item; UpdateItem ist chirurgisch — sie zu verwechseln ist der Grund, warum Attribute still verschwinden.

Das definierende Merkmal: ein Item, vollständiger Key

Jede Item-basierte Action zielt auf ein einzelnes Item über seinen vollständigen Primary Key. Genau das macht sie schnell und billig — DynamoDB hasht den Partition Key, geht direkt zum Item, fertig. Kein Filtern, kein Scannen. Wenn du den vollständigen Key nicht kennst, sind das nicht die richtigen Werkzeuge; dafür sind Query und Scan da.

Nimm an, du betreibst User-Accounts, gekeyed über USER#<id>:

PK: USER#204   email, displayName, plan, createdAt

GetItem auf USER#204 → dieser User, direkt.
DeleteItem auf USER#204 → entfernt diesen User.

Beide brauchen den exakten Key. Kein Key, keine Item-basierte Action.

`PutItem` vs. `UpdateItem` — die Falle

Das ist die Unterscheidung, die du dir einprägen solltest:

PutItem schreibt das gesamte Item. Wenn USER#204 schon existiert und du PutItem mit nur {email, displayName} aufrufst, sind die bestehenden Attribute plan und createdAt weg — ein Put ersetzt das ganze Item, es merged nicht.
UpdateItem ändert nur, was du nennst. UpdateItem mit einem SET email = … lässt jedes andere Attribut unangetastet und legt das Item an, falls es nicht existierte (ein Upsert).

Faustregel: greif zu UpdateItem, um ein bestehendes Item zu ändern, und nutze PutItem nur, wenn du wirklich meinst „schreibe dieses Item als den vollständigen neuen Zustand". Sowohl PutItem als auch UpdateItem akzeptieren eine Condition Expression, sodass du den Write bedingt machen kannst („nur, wenn es noch nicht existiert").

Item-basierte Actions in DynoTable

Willst du die rohen API-Aufrufe hinter diesen Aktionen sehen? Stell die Expressions und typisierten Wert-Maps im DynamoDB Expression Builder zusammen und konvertiere ein Plain-JSON-Item mit dem DynamoDB JSON Converter in das typisierte Format der API.

In DynoTable ist dieselbe Arbeit visuell: öffne ein Item im Grid, um es zu lesen (ein GetItem), bearbeite Attribute und committe (ein UpdateItem), füge eine Zeile hinzu oder ersetze sie (ein PutItem), oder lösche eine — ein Item auf einmal.

Ein einzelnes Item in DynoTables Quick View lesen, mit den Aktionen Edit Item und Copy as JSON.

Fallstricke und nächste Schritte

PutItem ersetzt das ganze Item — um ein paar Felder zu ändern, ohne den Rest zu verlieren, nutze UpdateItem.
Du musst den vollständigen Primary Key kennen — kein Key bedeutet Query/Scan, keine Item-Action.
Viele Items auf einmal? Schleife sie nicht einzeln durch — Batch-Operationen falten sie in weniger Round-Trips.
Brauchst du den alten/neuen Wert zurück? Setze ReturnValues statt eines nachgelagerten GetItem.
Verwandt: Query vs. Scan behandelt die Read-Many-Seite.

Willst du Items lesen, schreiben und löschen, ohne eine Zeile API-Code zu schreiben? Lade DynoTable herunter und arbeite direkt mit deinen Tabellen.