SQL Workbench

Le Workbench est un onglet d’écriture SQL qui exécute de vraies requêtes JOIN, GROUP BY et agrégées sur tes tables DynamoDB — ce que PartiQL ne peut pas faire. C’est du SQL dans les règles de modèle d’accès de DynamoDB : tu écris un seul SELECT, un compilateur vérifie que chaque jointure lit à travers une vraie clé ou un vrai index, matérialise les lignes jointes, et exécute le reste de l’instruction par-dessus — filtres, agrégats, GROUP BY, ORDER BY.

Ouvres-en un depuis le menu clic droit de la barre latérale (Nouveau Workbench), le raccourci ⌘⌥B, ou Fichier → Nouveau Workbench. Écris du SQL, puis appuie sur ⌘↩ pour exécuter.

L’éditeur suggère les noms de tables, plus les champs et valeurs indexés selon le contexte SQL au niveau du curseur. Voir Stats de table pour ce que contient l’index local et comment le rafraîchir.

SELECT c.email, COUNT(*) AS orders, SUM(o.total) AS revenue
FROM orders o
JOIN customers c ON o.customerId = c.id
GROUP BY c.email
ORDER BY revenue DESC

Le Workbench : un JOIN SQL multi-tables, avec la grille de résultats jointe en dessous.

Ce qu’il prend en charge

Une seule instruction SELECT avec :

JOIN ... ON ... — jointures INNER et LEFT entre tables.
Agrégats — COUNT, SUM, AVG, MIN, MAX, plus GROUP BY et HAVING.
WHERE, DISTINCT, CASE, CAST, ORDER BY.

Tant qu’une requête agrégée est encore en streaming, un badge partial marque les colonnes affectées — les nombres s’affinent à mesure que les pages arrivent.

La règle de modèle d’accès

DynamoDB n’a pas de jointures côté serveur. Le compilateur du Workbench impose ce que DynamoDB peut faire : l’attribut côté arrivée de chaque JOIN doit être une clé de partition ou une clé de partition de GSI sur la table cible, pour que chaque lookup soit une vraie query, jamais un scan de table complet caché par ligne.

Si une jointure pointe vers un attribut non-clé, l’éditeur le souligne et explique pourquoi. Les autres rejets du compilateur apparaissent eux aussi comme des soulignements de validation précis. Le Workbench ne propose pas de correction rapide :

Les jointures RIGHT / FULL OUTER / CROSS et les comma-joins (seulement INNER / LEFT).
Les sous-requêtes, les CTE (WITH), UNION / INTERSECT / EXCEPT.
Les fonctions de fenêtrage (OVER), les instructions multiples, tout ce qui n’est pas un SELECT.

Lecture seule

Un Workbench est toujours en lecture seule. Il n’y a pas d’édition, de staging ni de suppression en lot — c’est une surface d’analyse. Exécuter une requête n’écrit jamais dans tes tables.

Les identifiants suivent la casse SQL standard : les noms non quotés correspondent sans tenir compte de la casse (WHERE PLATFORM trouve platform) ; entoure un nom de guillemets ou de backticks pour une correspondance sensible à la casse.

Aperçu du coût de la requête

Quand un plan est disponible, l’aperçu identifie Scan ou Query et l’index ; l’estimation RCU n’apparaît que si les métadonnées de la table le permettent.

Cette barre d’état apparaît dans le Workbench et PartiQL, pas dans la rangée de filtres visuels. Un SQL vide, un échec de compilation, du DML ou du PartiQL inanalysable n’a pas de plan : aucune barre de coût n’apparaît.

Une Query de partition ordinaire affiche « le coût dépend des éléments correspondants » et aucun RCU. Une lecture ponctuelle et un Scan dont la taille est connue ne donnent pas non plus de RCU sans métadonnées DescribeTable.

Une lecture ponctuelle affiche quand même « ≈1 élément ». Un Scan avec un nombre d’éléments peut afficher une estimation de table, mais calculer son RCU exige la taille de la table en octets. Sans l’une ou l’autre valeur, un Scan indique « taille inconnue ».

Les estimations de Scan utilisent les chiffres de table que DynamoDB rafraîchit périodiquement, pas des valeurs en direct. La branche lecture ponctuelle tarife une lecture fortement cohérente ; la branche Scan tarife une lecture en cohérence à terme.

Le Workbench comme PartiQL exécutent des lectures en cohérence à terme. L’estimation de la lecture ponctuelle peut donc valoir le double du coût réel de la requête. Traite chaque chiffre comme un indice avant exécution, pas comme une facture.

Exécution, modèles et historique

Run — ⌘↩ dans l’éditeur, le bouton Run, ou ⌘R pour réexécuter. Les onglets Workbench ne s’exécutent jamais automatiquement à l’ouverture ; l’exécution est toujours délibérée.
Run to end — ⌘⇧↩, ou choisis-le dans le menu scindé du bouton Run, pour streamer tout le résultat joint au lieu d’une seule page. La limite de page est levée et les pages continuent d’arriver jusqu’à épuisement de la requête ; Stop est le seul frein. Pratique pour les gros agrégats que tu veux complets en une seule passe.
Modèles et requêtes enregistrées — le menu Requêtes rassemble les modèles de départ (select-all, filter-by-key, count-by-group, avec des trous à tabuler) ainsi que toute requête que tu conserves avec Enregistrer — tes propres requêtes nommées, réutilisables sur n’importe quelle table. En choisir une remplace le contenu de l’éditeur, pour qu’elle s’exécute exactement comme tu l’as enregistrée.
Historique — chaque exécution est enregistrée (séparément de l’historique de PartiQL), cherchable et restaurable — y compris les exécutions échouées, pour que tu puisses corriger et réessayer.

Un onglet Workbench est une spec enregistrée — nomme-la, rouvre-la depuis ⌘K, et elle survit aux rechargements. Tu peux aussi exporter ses résultats joints.

Workbench vs Smart Table

Les deux exécutent le même moteur de jointure ; ce sont deux façons de créer la même chose :

Workbench est la voie SQL — tape une requête, obtiens des agrégats et des attributs résolus.
Smart Table est la voie visuelle — dessine les jointures sur un canevas et parcours les lignes jointes comme une table normale.