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 Zugriffsmuster-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 den Rest der Anweisung — Filter, Aggregate, GROUP BY, ORDER BY — 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.

Der Editor schlägt Tabellennamen vor, dazu indizierte Felder und Werte auf Basis des SQL-Kontexts an der Cursorposition. Was der lokale Index enthält und wie du ihn aktualisierst, steht unter Tabellenstatistiken.

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

Die Workbench: ein Multi-Tabellen-SQL-JOIN, mit dem verknüpften Ergebnisraster darunter.

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 Zugriffsmuster-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 -Partition-Key auf der Zieltabelle sein, sodass jedes Lookup eine echte Abfrage ist, nie ein versteckter vollständiger Tabellen- pro Zeile.

Zeigt ein Join auf ein Nicht-Key-Attribut, unterstreicht der Editor es und erklärt warum. Auch andere Ablehnungen des Compilers erscheinen als präzise Validierungs-Schlängellinien. Die Workbench bietet keine Quick-Fixes an:

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.

Preview the query cost

Wenn ein Plan verfügbar ist, weist die Vorschau Scan gegenüber Query und den Index aus; die RCU-Schätzung erscheint nur, wenn die Tabellenmetadaten sie hergeben.

Diese Statusleiste erscheint in Workbench und PartiQL, nicht in der visuellen Filterzeile. Leeres SQL, ein Compile-Fehler, DML oder nicht parsebares PartiQL hat keinen Plan, also erscheint auch keine Kostenleiste.

Eine gewöhnliche Partition-Query zeigt „Kosten hängen von den passenden Items ab“ und keine RCU. Auch ein Point Read und ein Scan mit Größenangabe liefern ohne unterstützende DescribeTable-Metadaten keine RCU.

Ein Point Read zeigt weiterhin „≈1 Item“. Ein Scan mit Item-Anzahl kann eine Tabellenschätzung zeigen, aber die Berechnung seiner RCU braucht die Tabellengröße in Bytes. Fehlt einer der beiden Werte, sagt ein Scan „Größe unbekannt“.

Scan-Schätzungen nutzen DynamoDBs periodisch aktualisierte Tabellenzahlen, keine Live-Werte. Der Point-Read-Zweig rechnet mit starker Konsistenz, der Scan-Zweig mit letztendlicher Konsistenz.

Workbench und PartiQL führen beide letztendlich konsistente Lesevorgänge aus. Die Point-Read-Schätzung kann deshalb doppelt so hoch sein wie die tatsächlichen Kosten der Anfrage. Behandle jede Zahl als Hinweis vor dem Lauf, nicht als Rechnung.

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; Stoppen 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 Speichern 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.