SQL-Workbench

Die Workbench ist ein SQL-Authoring-Tab, der echte JOIN-, GROUP BY- und Aggregat-Abfragen über deine DynamoDB-Tabellen ausführt — die Dinge, die PartiQL nicht kann. Es ist SQL innerhalb der Access-Pattern-Regeln von DynamoDB: Du schreibst ein einzelnes SELECT, ein Compiler prüft, dass jeder Join über einen echten Key oder Index liest, materialisiert die verknüpften Zeilen und führt dein vollständiges SQL darauf aus.

Öffne eine über das Rechtsklick-Menü der Seitenleiste (Neue Workbench), das ⌘⌥B-Kürzel oder Datei → Neue Workbench. Schreibe SQL, dann drücke ⌘↩ zum Ausführen.

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

Was sie unterstützt

Eine einzelne SELECT-Anweisung mit:

• JOIN ... ON ... — INNER- und LEFT-Joins über Tabellen.
• Aggregate — COUNT, SUM, AVG, MIN, MAX, plus GROUP BY und HAVING.
• WHERE, DISTINCT, CASE, CAST, ORDER BY.

Während eine Aggregat-Abfrage noch streamt, markiert ein partial-Badge die betroffenen Spalten — die Zahlen verfeinern sich, während mehr Seiten ankommen.

Die Access-Pattern-Regel

DynamoDB hat keine serverseitigen Joins. Der Workbench-Compiler erzwingt, was DynamoDB kann: das To-Side-Attribut jedes JOIN muss ein Partition Key oder ein GSI-Partition-Key auf der Zieltabelle sein, sodass jedes Lookup eine echte Abfrage ist, nie ein versteckter vollständiger Tabellen-Scan pro Zeile.

Zeigt ein Join auf ein Nicht-Key-Attribut, unterstreicht der Editor es und erklärt warum. Andere Konstrukte lehnt der Compiler vorab ab, mit einer präzisen Schlängellinie:

• RIGHT- / FULL OUTER- / CROSS-Joins und Komma-Joins (nur INNER / LEFT).
• Unterabfragen, CTEs (WITH), UNION / INTERSECT / EXCEPT.
• Fensterfunktionen (OVER), mehrere Anweisungen, alles, was kein SELECT ist.

Schreibgeschützt

Eine Workbench ist immer schreibgeschützt. Es gibt kein Bearbeiten, Staging oder Stapel-Löschen — es ist eine Analyse-Oberfläche. Das Ausführen einer Abfrage schreibt nie in deine Tabellen.

Bezeichner folgen der standardmäßigen SQL-Groß-/Kleinschreibung: nicht in Anführungszeichen gesetzte Namen passen ohne Berücksichtigung der Groß-/Kleinschreibung (WHERE PLATFORM findet platform); umschließe einen Namen mit Anführungszeichen oder Backticks für exakte Groß-/Kleinschreibung.

Ausführen, Vorlagen und Verlauf

• Ausführen — ⌘↩ im Editor, die Run-Schaltfläche oder ⌘R zum erneuten Ausführen. Workbench-Tabs laufen nie automatisch beim Öffnen; die Ausführung ist immer bewusst.
• Bis zum Ende ausführen — ⌘⇧↩, oder wähle es aus dem Split-Menü der Run-Schaltfläche, um das vollständige verknüpfte Ergebnis statt einer Seite zu streamen. Die Seitenobergrenze wird aufgehoben und es kommen weiter Seiten an, bis die Abfrage erschöpft ist; Stopp ist die einzige Bremse. Praktisch für große Aggregate, die du in einem Durchlauf vollständig haben willst.
• Vorlagen & gespeicherte Abfragen — das Queries-Menü enthält Start-Vorlagen (Alles auswählen, Nach-Key-filtern, Nach-Gruppe-zählen, mit Tab-durchlaufbaren Lücken) sowie jede Abfrage, die du mit Save behältst — deine eigenen benannten Abfragen, auf jeder Tabelle wiederverwendbar. Eine auszuwählen ersetzt den Inhalt des Editors, sodass sie genau so läuft, wie du sie gespeichert hast.
• Verlauf — jeder Lauf wird gespeichert (getrennt vom PartiQL-Verlauf), durchsuchbar und wiederherstellbar — fehlgeschlagene Läufe eingeschlossen, sodass du sie korrigieren und erneut versuchen kannst.

Ein Workbench-Tab ist eine gespeicherte Spezifikation — benenne ihn, öffne ihn erneut über ⌘K, und er übersteht Neuladevorgänge. Du kannst auch seine verknüpften Ergebnisse exportieren.

Workbench vs. Smart Table

Beide führen dieselbe Join-Engine aus; sie sind zwei Wege, dasselbe zu autoren:

• Workbench ist die SQL-Spur — tippe eine Abfrage, erhalte Aggregate und aufgelöste Attribute.
• Smart Table ist die visuelle Spur — zeichne die Joins auf einem Canvas und durchsuche die verknüpften Zeilen wie eine normale Tabelle.