DynamoDB prend-il en charge les clés étrangères ?

Non. DynamoDB n'a ni clés étrangères, ni contraintes d'intégrité référentielle, ni suppressions en cascade — en tant que base de données NoSQL, il n'impose jamais de relation entre des éléments ou des tables. C'est toi qui modélises les relations : dénormalise les données liées dans un seul élément, ou co-localise les éléments liés sous une clé de partition partagée avec le single-table design. Pour voir et parcourir ces relations modélisées, les Smart Tables de DynoTable dessinent une relation entre deux tables sur un canevas et parcourent les lignes jointes.

Pourquoi il n'y a pas de clés étrangères

Une clé étrangère existe pour soutenir les jointures et imposer l'intégrité entre des tables normalisées. DynamoDB omet délibérément l'opérateur JOIN (AWS recommande de dénormaliser à la place) : une contrainte de clé étrangère surveillerait donc une relation que le modèle de requête n'exploite jamais. Rien ne t'empêche de stocker la clé d'un autre élément comme attribut — DynamoDB ne la validera ni ne la cascadera, tout simplement.

Comment les relations se modélisent à la place

Imbriquer — les données enfants petites et bornées vivent dans l'élément parent, sous forme de liste ou de map.
Co-localiser — parent et enfants partagent une clé de partition avec des clés de tri distinctes, si bien qu'un seul Query renvoie toute la relation ; c'est le cœur du single-table design.
Dupliquer — copie les champs dont chaque modèle d'accès a besoin sur les éléments qui en ont besoin, en acceptant l'entretien à l'écriture pour des lectures en une seule requête.

Les guides un-à-plusieurs et plusieurs-à-plusieurs traitent chaque forme en profondeur.

Imposer l'intégrité quand ça compte

Pour les cas où tu te serais appuyé sur une contrainte, DynamoDB te donne des briques : les expressions de condition protègent une écriture selon l'état de l'élément écrit, et le ConditionCheck d'une transaction peut vérifier qu'un autre élément (le parent, disons) existe dans la même opération tout-ou-rien. Les suppressions en cascade deviennent de la logique applicative explicite ou un nettoyage piloté par Streams.

À quoi ça ressemble quand tu l'exécutes

Nous avons placé un élément PROFILE et deux éléments ORDER# sous pk = "CUSTOMER#1", supprimé le profil, puis interrogé la partition à nouveau :

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

La suppression a renvoyé un succès. Deux orphelins, aucun avertissement, aucune erreur à attraper. Dans PostgreSQL, la même suppression échoue, cascade ou met la référence enfant à null, selon la contrainte que tu as déclarée.

Puis le remplacement le plus proche : un TransactWriteItems qui vérifie par condition le parent avant d'écrire une troisième commande.

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

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

Les positions du tableau correspondent aux positions de tes TransactItems : [ConditionalCheckFailed, None] dit donc que l'action 0 (la vérification du parent) a échoué et que l'action 1 (l'écriture de l'enfant) allait bien. Avec une seule garde ça se lit tout seul ; avec huit actions, ce tableau est le seul moyen de savoir laquelle a cassé.

Ça se facture aussi. Une écriture transactionnelle consomme deux unités d'écriture par élément, et AWS est explicite : "this capacity is consumed even when the transaction is canceled". Chaque écriture rejetée coûte autant qu'une écriture acceptée.

Aller plus loin

Commence par le single-table design, construis les conditions de garde dans l'expression builder, et télécharge DynoTable pour parcourir ces relations visuellement — ses Smart Tables joignent tables parent et enfant sur un canevas pour que tu voies toute la collection d'éléments d'un seul coup d'œil.

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.

La requête sur les enfants orphelins et la sortie d'annulation ont été reproduites le 2026-07-28 sur DynamoDB Local 3.3.0 avec @aws-sdk/client-dynamodb 3.1095.0 sur Node v24.18.0.