DynamoDB prend-il en charge les jointures ?

Pas dans la base de données elle-même. En tant que base de données non relationnelle, DynamoDB n'a aucune opération JOIN, et PartiQL n'en ajoute pas : pour les lectures en production, tu modélises donc les données liées autrement — dénormalise (duplique-les ou imbrique-les pour que chaque modèle d'accès tienne en une requête) ou utilise le single-table design pour co-localiser les éléments liés sous une même clé de partition. Mais tu peux quand même exécuter une vraie jointure sur tes tables DynamoDB depuis un client : le SQL Workbench de DynoTable exécute de vraies requêtes JOIN, GROUP BY et d'agrégation sur tes données en direct.

Pourquoi la base de données n'a pas de jointure

DynamoDB est conçu pour des lectures prévisibles de quelques millisecondes à n'importe quelle échelle. Joindre au moment de la lecture ferait dépendre la latence de la quantité de données liées, ce qui casserait cette garantie. Pour tes modèles d'accès modélisés, la jointure se fait donc à l'écriture, par toi.

Ce qui se passe si tu essaies

PartiQL rejette l'instruction dans l'analyseur, avant de lire quoi que ce soit. La jointure explicite et le produit croisé par virgule échouent de la même façon :

SELECT o."total", c."name" FROM "Orders" o JOIN "Customers" c ON o."pk" = c."id"
SELECT * FROM "Orders", "Customers"

ValidationException: Only select from a single table or index is supported.
HTTP 400

Il n'y a donc pas de solution de repli lente-mais-fonctionnelle à découvrir en production. Une instruction qui nomme deux tables est une erreur de syntaxe, et le travail doit se déplacer ailleurs : dans ton modèle de données, ou dans un client qui fait lui-même la partie relationnelle.

Ce que tu fais pour les modèles d'accès modélisés

Dénormalisation — copie ou imbrique les données liées que tu lis ensemble.
Single-table design — stocke plusieurs types d'entités dans une table avec des clés surchargées, pour qu'une collection d'éléments les lise ensemble en un seul Query.
Listes d'adjacence — modélise les relations plusieurs-à-plusieurs sous forme d'éléments interrogeables par clé.

Cela garde les lectures de production à une seule requête. Déroulé complet dans les jointures DynamoDB.

Exécuter un vrai JOIN avec DynoTable

Pour la question ad hoc, inter-tables, que tu n'avais pas modélisée — « quels clients de l'UE ont dépensé plus de 500 $ le mois dernier ? » sur une table Orders et une table Customers — DynoTable exécute cette jointure pour toi. C'est un client DynamoDB de bureau, et son SQL Workbench exécute de vraies requêtes JOIN, GROUP BY et d'agrégation : il lit les éléments via l'API DynamoDB normale, puis exécute la partie relationnelle de la requête dans le client. Ceci fonctionne donc, sur des tables sans aucune relation définie et avec un moteur de requête dépourvu de mot-clé JOIN :

SELECT   c.name, SUM(o.total) AS spend
FROM     Customers c
JOIN     Orders o ON o.customerId = c.id
WHERE    c.region = 'EU'
GROUP BY c.name

Tu préfères ne pas écrire de SQL ? Les Smart Tables sont la voie visuelle vers le même moteur de jointure : trace une ligne de relation entre deux tables sur un canevas et parcours les lignes jointes.

La réserve honnête, « dans le cadre des règles d'access-pattern de DynamoDB » : le Workbench lit toujours à travers DynamoDB, donc les jointures les plus rapides sont celles dont l'attribut du ON ou la clause WHERE tombe sur une clé de partition ou un GSI d'au moins un côté, ce qui permet à DynamoDB d'exécuter un Query plutôt qu'un scan complet. Vois /docs/dynamodb-sql-workbench pour le comportement du Workbench et /docs/smart-tables pour le canevas de jointure visuel. DynoTable te permet de poser la question de la jointure au lieu de recoudre les résultats à la main dans du code ; il n'abroge pas les contraintes ci-dessus. Parmi les clients GUI DynamoDB, c'est le seul « oui, tu peux joindre » qui soit réellement vrai : PartiQL et le NoSQL Workbench d'AWS s'arrêtent tous deux au mur de la table unique.

Pour des lectures en table unique qui évitent complètement les jointures, esquisse des clés surchargées dans l'outil de conception à table unique avant de modéliser des copies dénormalisées de données liées.

Le compromis

Pour les chemins de lecture en production, tu fais un travail plus soigné sur les écritures afin de rendre les lectures bon marché et à temps constant.

Aller plus loin

Lis les jointures DynamoDB, le single-table design et les relations un-à-plusieurs. Télécharge DynoTable pour exécuter un vrai JOIN sur tes tables, en SQL ou visuellement avec les Smart Tables.

Références

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

La ValidationException ci-dessus a été reproduite le 2026-07-28 sur DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 et est citée telle quelle.