Los problemas de SQL y cómo resolverlos: la sintaxis de tuberías en SQL

• SQL se ha consolidado durante 50 años como el lenguaje base para el procesamiento de datos estructurados, pero es difícil de aprender, complicado de usar y difícil de extender
• Problemas del SQL tradicional: orden de sintaxis forzado, sintaxis duplicada, necesidad de usar subconsultas, flujo de datos “de adentro hacia afuera”, falta de extensibilidad, etc.
• En GoogleSQL adoptaron un enfoque de extender SQL para resolver estos problemas
  • Buscan resolver los problemas del SQL tradicional introduciendo en SQL una sintaxis de flujo de datos con estructura de tuberías
  • Permite aprender y usar SQL de forma más flexible manteniendo el ecosistema existente y conservando compatibilidad total con el SQL actual
    • Reutiliza los operadores SQL existentes y permite componerlos con tuberías en un orden arbitrario
    • Cada operador de tubería solo puede ver la tabla de entrada, por lo que el alcance queda claramente definido
    • Mantiene la semántica declarativa
    • Hace posible una correspondencia uno a uno con el álgebra relacional
    • Mejora la extensibilidad mediante funciones con valor de tabla
  • Por ejemplo, permite expresar agregaciones de múltiples etapas de forma continua sin subconsultas
  • El SQL con sintaxis de tuberías es más fácil de aprender y usar, y mejora mucho la flexibilidad al permitir aplicar diversos operadores en cualquier orden
  • Los operadores de tubería funcionan de manera secuencial, lo que facilita a los usuarios filtrar, agregar y ordenar datos
• Experiencia de uso en GoogleSQL
  • Ha recibido adopción constante por parte de los usuarios y comentarios positivos
  • Incluso las consultas complejas pueden expresarse de forma lineal
  • Facilita las tareas de edición y depuración
  • Mejora el soporte de herramientas en los IDE
  • Es favorable para generadores y convertidores de código SQL
  • Tiene ventajas potenciales para aplicaciones de IA
• Implementación y planes a futuro
  • La sintaxis de tuberías se implementó en GoogleSQL como un componente compartido
  • Los motores de consulta existentes pueden habilitar fácilmente la sintaxis de tuberías
  • Se está evaluando ofrecer soporte externo en BigQuery y Spanner
  • Vale la pena explorar su inclusión futura en el estándar SQL

Opinión de GN⁺

• Ventajas de la sintaxis de tuberías: puede actuar como una herramienta poderosa para resolver la complejidad de SQL y, en particular, mejorar mucho su usabilidad al expresar el flujo de datos de manera intuitiva.
• Compatibilidad con el SQL existente: en lugar de reemplazar el SQL actual, el enfoque apunta a mejorarlo, reduciendo la curva de aprendizaje y manteniendo la compatibilidad con el código existente.
• Aspectos a considerar al adoptarla: al adoptar la sintaxis de tuberías, hay que considerar su impacto en el rendimiento y el nivel de soporte de herramientas; en particular, sus ventajas pueden aprovecharse al máximo en consultas de gran escala.
• Comparación con proyectos similares: las estructuras de tuberías también se usan en API de DataFrame como Pandas, pero la diferencia en SQL es su combinación con la semántica declarativa. Esto permite usar estas capacidades manteniendo la extensibilidad y el rendimiento de los sistemas SQL.

[dkang]

Un pipe con caret... suena como una combinación que te va a dejar doliendo la mano derecha 🤣
Sí, parece que SQL sí necesita alguna mejora.
Aunque el problema es que en unos 30 o 40 años no han encontrado una propuesta de mejora.

[savvykang]

Parece que Google tendría que liderar el ecosistema en cuanto a sintaxis adicional de SQL, pero ¿de verdad la división de negocio va a mantener esto a largo plazo?

[chusine]

Es dplyr, jajajaja

[koreaisbest]

¿Por qué siento que si Google lo hace, solo va a fracasar?..
Además, Gemini responde como un chamaco, así que ni dan ganas de usarlo

[ilotoki0804]

Parece similar al enfoque que adoptan los ORM

[winterjung]

Con solo ver el ejemplo de abajo del paper, queda claro que Google SQL sí es más fácil de leer.

standard sql

SELECT c_count, COUNT(*) AS custdist  
FROM  
    ( SELECT c_custkey, COUNT(o_orderkey) c_count  
      FROM customer  
      LEFT OUTER JOIN orders ON c_custkey = o_custkey  
           AND o_comment NOT LIKE '%unusual%packages%'  
      GROUP BY c_custkey  
    ) AS c_orders  
GROUP BY c_count  
ORDER BY custdist DESC, c_count DESC;  

google sql

FROM customer  
|> LEFT OUTER JOIN orders ON c_custkey = o_custkey  
      AND o_comment NOT LIKE '%unusual%packages%'  
|> AGGREGATE COUNT(o_orderkey) c_count  
   GROUP BY c_custkey  
|> AGGREGATE COUNT(*) AS custdist  
   GROUP BY c_count  
|> ORDER BY custdist DESC, c_count DESC;  

[mwma91]

Me recuerda a LINQ de C#. Cada vez que uso SQL siempre he pensado que ojalá el orden de SELECT cambiara para ir después de FROM y WHERE....
Aunque al principio se siente raro por falta de costumbre, si lo lees con calma, el flujo se siente mucho más natural.

[regentag]

Parece que la parte de SQL es más fácil de leer.

[leftliber]

A mí SQL me resulta mucho más fácil de leer. Jaja, supongo que a la mayoría de los que empezaron con SQL les pasa igual...

[superwoou]

A mí también se me hace más fácil de leer lo que ya conozco... jaja

[GN⁺]

Comentarios de Hacker News

• La sintaxis de tuberías de SQL se volvió más fácil de leer
• En Google, la sintaxis de tuberías fue útil al escribir consultas SQL
• Esperan que la sintaxis de tuberías de SQL se generalice
• El resultado de convertir un PDF a HTML en Google AI Studio fue bueno
• Aunque llevan más de 20 años usando SQL, todavía les cuesta expresar ciertas consultas
• El proyecto de código abierto ZetaSQL de Google agregó documentación sobre la sintaxis de tuberías
• Las quejas sobre la sintaxis de SQL tienen baja prioridad
  • Se necesitan funciones como tipos de datos algebraicos, lógica booleana real y composición funcional
• Ha habido muchos intentos de reducir la dificultad de escribir SQL, pero no han tenido éxito
  • El enfoque de los autores es gradual y adecuado para usuarios existentes de SQL
• La sintaxis de pipeline es mejor que el estado actual
  • Sería mejor una sintaxis que modele la ejecución de consultas como un grafo dirigido acíclico de tareas
    • Los joins pueden modelarse como una operación de "referencia cruzada" que consume dos o más flujos de datos y produce un flujo de datos
    • Los CTE pueden modelarse como algo que genera varios flujos de datos
    • Los CTE recursivos pueden modelarse como ciclos en el grafo de ejecución
• Es similar a Elixir
  • Si se admite la sintaxis existente de SQL, está bien, pero las consultas con varios JOIN, subconsultas y agregaciones pueden perder legibilidad
• Hace pensar en PRQL y en SPL de Splunk