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 ton SQL complet par-dessus.

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.

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

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. Le compilateur rejette d’emblée d’autres constructions, avec un soulignement précis :

• 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.

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.