DynamoDB supporta le chiavi esterne?

No. DynamoDB non ha chiavi esterne, vincoli di integrità referenziale né eliminazioni a cascata — essendo un database NoSQL non impone mai relazioni tra Item o tabelle. Le relazioni le modelli tu: denormalizza i dati correlati in un unico Item, oppure colloca gli Item correlati sotto una partition key condivisa con la progettazione a tabella singola. Per vedere e attraversare quelle relazioni modellate, le Smart Tables di DynoTable disegnano una relazione tra due tabelle su un canvas e ti fanno sfogliare le righe unite.

Perché non ci sono chiavi esterne

Una chiave esterna esiste per supportare i join e imporre l'integrità tra tabelle normalizzate. DynamoDB omette deliberatamente l'operatore JOIN (AWS consiglia invece di denormalizzare), quindi un vincolo di chiave esterna sorveglierebbe una relazione che il modello di query non sfrutta mai. Nulla ti impedisce di memorizzare la chiave di un altro Item come attributo — semplicemente DynamoDB non la validerà né la propagherà a cascata.

Come si modellano invece le relazioni

Incorpora — i dati figli piccoli e limitati vivono dentro l'Item padre come list o map.
Colloca insieme — padre e figli condividono una partition key con sort key distinte, così una sola Query restituisce l'intera relazione; è il cuore della progettazione a tabella singola.
Duplica — copia i campi di cui ha bisogno ciascun pattern di accesso sugli Item che ne hanno bisogno, accettando manutenzione in scrittura in cambio di letture in una sola richiesta.

Le guide su uno-a-molti e molti-a-molti trattano ciascuna forma in profondità.

Imporre l'integrità quando conta

Per i casi in cui ti saresti appoggiato a un vincolo, DynamoDB ti dà dei mattoncini: le espressioni di condizione proteggono una scrittura in base allo stato dell'Item che viene scritto, e il ConditionCheck di una transazione può verificare che un Item diverso (per esempio il padre) esista nella stessa operazione tutto-o-niente. Le eliminazioni a cascata diventano logica applicativa esplicita o una pulizia guidata dagli Streams.

Che aspetto ha quando lo esegui

Abbiamo messo un Item PROFILE e due Item ORDER# sotto pk = "CUSTOMER#1", abbiamo eliminato il profilo e abbiamo interrogato di nuovo la partizione:

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

L'eliminazione ha restituito successo. Due orfani, nessun avviso, nessun errore da catturare. In PostgreSQL la stessa eliminazione fallisce, va a cascata o azzera il riferimento del figlio, a seconda del vincolo che hai dichiarato.

Poi il sostituto più vicino: un TransactWriteItems che fa un condition check sul padre prima di scrivere un terzo ordine.

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

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

Le posizioni dell'array corrispondono alle posizioni dei tuoi TransactItems, quindi [ConditionalCheckFailed, None] dice che l'azione 0 (il check sul padre) è fallita e che l'azione 1 (la scrittura del figlio) andava bene. Con una sola guardia si legge senza fatica; con otto azioni, quell'array è l'unico modo per scoprire quale si è rotta.

E si paga, per giunta. Una scrittura transazionale consuma due unità di scrittura per Item, e AWS è esplicita nel dire che "this capacity is consumed even when the transaction is canceled". Ogni scrittura rifiutata costa quanto una accettata.

Approfondisci

Parti dalla progettazione a tabella singola, costruisci le condizioni di guardia nell'expression builder e scarica DynoTable per sfogliare quelle relazioni visivamente — le sue Smart Tables uniscono tabelle padre e figlie su un canvas così vedi l'intera collezione di Item in un'unica vista.

Riferimenti

Ultima verifica 2026-07-13 rispetto alla documentazione ufficiale AWS collegata sopra.

La query sui figli orfani e l'output di cancellazione sono stati riprodotti il 2026-07-28 su DynamoDB Local 3.3.0 con @aws-sdk/client-dynamodb 3.1095.0 su Node v24.18.0.