Workbench SQL

Il Workbench è un tab di scrittura SQL che esegue vere query con JOIN, GROUP BY e aggregazioni sulle tue tabelle DynamoDB: le cose che PartiQL non sa fare. È SQL entro le regole dei pattern di accesso di DynamoDB: scrivi un singolo SELECT, un compilatore verifica che ogni join legga attraverso una chiave o un indice reale, materializza le righe unite ed esegue il resto dell'istruzione — filtri, aggregazioni, GROUP BY, ORDER BY — al di sopra.

Aprine uno dal menu contestuale della sidebar (Nuovo Workbench), con la scorciatoia ⌘⌥B oppure da File → Nuovo Workbench. Scrivi SQL, poi premi ⌘↩ per eseguire.

L'editor suggerisce nomi di tabella, più campi e valori indicizzati in base al contesto SQL sotto il cursore. Vedi Statistiche della tabella per cosa contiene l'indice locale e come aggiornarlo.

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

Il Workbench: un JOIN SQL su più tabelle, con la griglia del risultato unito sotto.

Cosa supporta

Una singola istruzione SELECT con:

JOIN ... ON ... — join INNER e LEFT tra tabelle.
Aggregazioni — COUNT, SUM, AVG, MIN, MAX, più GROUP BY e HAVING.
WHERE, DISTINCT, CASE, CAST, ORDER BY.

Mentre una query di aggregazione è ancora in streaming, un badge partial segna le colonne interessate: i numeri si affinano man mano che arrivano altre pagine.

La regola dei pattern di accesso

DynamoDB non ha join lato server. Il compilatore del Workbench impone ciò che DynamoDB sa fare: l'attributo di destinazione di ogni JOIN deve essere una chiave di partizione o una chiave di partizione di un sulla tabella di arrivo, così ogni lookup è una query vera e mai uno nascosto dell'intera tabella per ogni riga.

Se un join punta a un attributo non di chiave, l'editor lo sottolinea e spiega perché. Anche gli altri rifiuti del compilatore compaiono come segnalazioni di validazione precise. Il Workbench non offre correzioni rapide:

Join RIGHT / FULL OUTER / CROSS e join con la virgola (solo INNER / LEFT).
Subquery, CTE (WITH), UNION / INTERSECT / EXCEPT.
Funzioni finestra (OVER), istruzioni multiple, qualsiasi cosa che non sia un SELECT.

Sola lettura

Un Workbench è sempre in sola lettura. Non c'è modifica, né staging, né eliminazione in blocco: è una superficie di analisi. Eseguire una query non scrive mai sulle tue tabelle.

Gli identificatori seguono le regole standard di SQL sulle maiuscole: i nomi non quotati corrispondono senza distinzione tra maiuscole e minuscole (WHERE PLATFORM trova platform); racchiudi un nome tra apici o backtick per una corrispondenza esatta.

Preview the query cost

Quando è disponibile un piano, l'anteprima indica se si tratta di Scan o Query e su quale indice; la stima delle RCU compare solo se i metadati della tabella lo consentono.

Questa barra di stato compare nel Workbench e in PartiQL, non nella riga dei filtri visuali. SQL vuoto, un errore di compilazione, DML o PartiQL non interpretabile non hanno un piano, quindi non compare alcuna barra dei costi.

Una normale Query su partizione mostra “il costo dipende dagli item corrispondenti” e nessuna RCU. Anche una lettura puntuale e uno Scan con dimensione nota non producono RCU senza i metadati di supporto di DescribeTable.

Una lettura puntuale mostra comunque “≈1 item”. Uno Scan con un numero di item può mostrare una stima della tabella, ma calcolarne le RCU richiede la dimensione della tabella in byte. Senza uno dei due valori, uno Scan dice “dimensione sconosciuta”.

Le stime di Scan usano i numeri della tabella che DynamoDB aggiorna periodicamente, non valori in tempo reale. Il ramo della lettura puntuale calcola il prezzo con l'elevata consistenza di lettura; il ramo Scan con la coerenza finale.

Sia il Workbench sia PartiQL eseguono letture a coerenza finale. La stima della lettura puntuale può quindi valere il doppio del costo reale della richiesta. Tratta ogni numero come un'indicazione prima dell'esecuzione, non come una fattura.

Esecuzione, template e cronologia

Esegui — ⌘↩ nell'editor, il pulsante Esegui, oppure ⌘R per rieseguire. I tab Workbench non partono mai da soli all'apertura: l'esecuzione è sempre deliberata.
Run to end — ⌘⇧↩, o sceglilo dallo split menu del pulsante Esegui, per scorrere in streaming l'intero risultato unito invece di una sola pagina. Il limite di pagina viene tolto e le pagine continuano ad arrivare finché la query non è esaurita; Stop è l'unico freno. Comodo per grandi aggregazioni che vuoi complete in una sola passata.
Template e query salvate — il menu Query contiene template di partenza (select-all, filtro per chiave, conteggio per gruppo, con buchi da percorrere con Tab) più ogni query che conservi con Salva: query tue, con un nome, riutilizzabili su qualsiasi tabella. Sceglierne una sostituisce il contenuto dell'editor, così viene eseguita esattamente come l'hai salvata.
Cronologia — ogni esecuzione viene salvata (separatamente dalla cronologia di PartiQL), è ricercabile e ripristinabile, comprese le esecuzioni fallite, così puoi correggerle e riprovare.

Un tab Workbench è una spec salvata: dagli un nome, riaprilo da ⌘K e sopravvive ai ricaricamenti. Puoi anche esportare i suoi risultati uniti.

Workbench e Smart Table a confronto

Entrambi usano lo stesso motore di join; sono due modi di scrivere la stessa cosa:

Il Workbench è la corsia SQL: scrivi una query e ottieni aggregazioni e attributi risolti.
La Smart Table è la corsia visuale: disegni i join su un canvas e sfogli le righe unite come una normale tabella.