SQL Workbench

El Workbench es una pestaña de autoría de SQL que ejecuta consultas reales de JOIN, GROUP BY y agregados entre tus tablas de DynamoDB — las cosas que PartiQL no puede hacer. Es SQL dentro de las reglas de patrones de acceso de DynamoDB: escribes un único SELECT, un compilador verifica que cada join lee a través de una clave o índice reales, materializa las filas unidas y ejecuta el resto de la sentencia encima — filtros, agregados, GROUP BY, ORDER BY.

Abre uno desde el menú contextual de la barra lateral (Nuevo Workbench), el atajo ⌘⌥B o Archivo → Nuevo Workbench. Escribe SQL, luego pulsa ⌘↩ para ejecutar.

El editor sugiere nombres de tabla, además de campos y valores indexados según el contexto SQL en el cursor. Consulta Estadísticas de tabla para ver qué contiene el índice local y cómo actualizarlo.

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
El Workbench: un JOIN SQL de varias tablas, con la cuadrícula de resultados unidos debajo.
El Workbench: un JOIN SQL de varias tablas, con la cuadrícula de resultados unidos debajo.

Qué soporta

Una única sentencia SELECT con:

  • JOIN ... ON ... — joins INNER y LEFT entre tablas.
  • AgregadosCOUNT, SUM, AVG, MIN, MAX, más GROUP BY y HAVING.
  • WHERE, DISTINCT, CASE, CAST, ORDER BY.

Mientras una consulta de agregado aún está en streaming, una insignia partial marca las columnas afectadas — los números se refinan a medida que llegan más páginas.

La regla de patrón de acceso

DynamoDB no tiene joins del lado del servidor. El compilador del Workbench impone lo que DynamoDB puede hacer: el atributo del lado destino de cada JOIN debe ser una clave de partición o una clave de partición de en la tabla objetivo, así que cada búsqueda es una Query real, nunca un de tabla completa oculto por fila.

Si un join apunta a un atributo que no es clave, el editor lo subraya y explica por qué. Los demás rechazos del compilador también aparecen como subrayados de validación precisos. El Workbench no ofrece correcciones rápidas:

  • Joins RIGHT / FULL OUTER / CROSS y joins por coma (solo INNER / LEFT).
  • Subconsultas, CTE (WITH), UNION / INTERSECT / EXCEPT.
  • Funciones de ventana (OVER), múltiples sentencias, cualquier cosa que no sea un SELECT.

Solo lectura

Un Workbench es siempre de solo lectura. No hay edición, preparación ni eliminación por lotes — es una superficie de análisis. Ejecutar una consulta nunca escribe en tus tablas.

Los identificadores siguen el casing estándar de SQL: los nombres sin comillas coinciden sin distinguir mayúsculas (WHERE PLATFORM encuentra platform); envuelve un nombre en comillas o backticks para coincidir con el caso exacto.

Preview the query cost

Cuando hay un plan disponible, la previsualización identifica Scan frente a Query y el índice; la estimación de RCU aparece solo cuando los metadatos de la tabla lo permiten.

Esta barra de estado aparece en el Workbench y en PartiQL, no en la fila de filtro visual. Un SQL vacío, un fallo de compilación, DML o un PartiQL que no se puede analizar no tienen plan, así que no aparece ninguna barra de coste.

Una Query de partición corriente muestra «el coste depende de los elementos coincidentes» y ningún RCU. Una lectura puntual y un Scan con tamaño tampoco dan RCU sin metadatos de DescribeTable que lo respalden.

Una lectura puntual sí muestra «≈1 elemento». Un Scan con recuento de elementos puede mostrar una estimación de la tabla, pero calcular su RCU requiere el tamaño de la tabla en bytes. Si falta cualquiera de los dos valores, un Scan dice «tamaño desconocido».

Las estimaciones de Scan usan las cifras de tabla que DynamoDB refresca periódicamente, no valores en vivo. La rama de lectura puntual calcula el precio con coherencia fuerte; la rama de Scan lo calcula con coherencia final.

Tanto el Workbench como PartiQL ejecutan lecturas con coherencia final. Por eso la estimación de la lectura puntual puede ser el doble del coste real de la solicitud. Trata cada número como una pista previa a la ejecución, no como una factura.

Ejecutar, plantillas e historial

  • Ejecutar⌘↩ en el editor, el botón de Ejecutar o ⌘R para volver a ejecutar. Las pestañas de Workbench nunca se ejecutan automáticamente al abrirse; la ejecución siempre es deliberada.
  • Ejecutar hasta el final⌘⇧↩, o elígelo desde el menú dividido del botón de Ejecutar, para transmitir el resultado unido completo en lugar de una sola página. El límite de páginas se levanta y las páginas siguen llegando hasta que la consulta se agota; Stop es el único freno. Útil para agregados grandes que quieres completar de una pasada.
  • Plantillas y consultas guardadas — el menú Queries contiene plantillas iniciales (seleccionar todo, filtrar por clave, contar por grupo, con huecos recorribles con Tab) más cualquier consulta que conserves con Save — tus propias consultas con nombre, reutilizables en cualquier tabla. Elegir una reemplaza el contenido del editor, así que se ejecuta exactamente como la guardaste.
  • Historial — cada ejecución se guarda (por separado del historial de PartiQL), es buscable y restaurable — incluidas las ejecuciones fallidas, para que puedas corregir y reintentar.

Una pestaña de Workbench es una especificación guardada — ponle nombre, reábrela desde ⌘K, y sobrevive a las recargas. También puedes exportar sus resultados unidos.

Workbench frente a Smart Table

Ambos ejecutan el mismo motor de joins; son dos formas de autoría de lo mismo:

  • Workbench es el carril de SQL — escribe una consulta, obtén agregados y atributos resueltos.
  • Smart Table es el carril visual — dibuja los joins en un lienzo y navega las filas unidas como una tabla normal.

Actualizado