SQL ha dominado la consulta de datos durante décadas. Los lenguajes de consulta más nuevos ofrecen más elegancia, simplicidad y flexibilidad para los casos de uso modernos.
por Peter Wayner
Durante las últimas tres décadas, las bases de datos y el lenguaje de consulta estructurado (SQL) fueron casi sinónimos. Cualquiera que quisiera recuperar información de una base de datos tenía que aprender SQL. Cualquiera que quisiera cuidar una base de datos o aceptar un trabajo como administrador de la base de datos necesitaba dominar sus matices.
El lenguaje en sí es un retroceso, una oportunidad para pensar y codificar como lo hicieron los usuarios de mainframe. Mientras que el resto del mundo adoptó las letras minúsculas, los usuarios de SQL continuaron escribiendo palabras como SELECCIONAR o DÓNDE. Incluso hoy en día, a pocos parece importarles que algunos usuarios de Tik Tok se burlen de ellos o les pregunten por qué están gritando. Si TODO EN MAYÚSCULAS era lo suficientemente bueno para los jinetes de cartas perforadas que usan corbatas y camisas de manga corta, bueno, todavía es lo suficientemente bueno para el trabajador remoto de hoy en día que usa un pijama de osito de peluche.
Pero el control de SQL sobre la recuperación de datos se está desvaneciendo. Están surgiendo nuevas bases de datos y algunas hablan idiomas completamente nuevos. No es que SQL se esté volviendo menos popular. En todo caso, se está escribiendo más SQL que nunca. Es solo que el mundo del almacenamiento de datos está explotando aún más rápido, y parte de ese crecimiento está estimulando la necesidad de experimentar y diversificarse.
Este artículo presenta ocho enfoques más nuevos para recuperar datos. En algunos casos, las innovaciones son meramente cosméticas. Los desarrolladores han actualizado la sintaxis de SQL para que sea un poco más ordenado y fácil de leer, por lo que es menos molesto cambiar de marcha entre escribir código para el navegador y recuperar datos. Los creadores de estas herramientas enfatizan que la estructura subyacente es esencialmente la misma que SQL. Seguirá siendo fácil de aprender. No te preocupes.
Otras herramientas nos invitan a pensar de una manera completamente diferente. Las bases de datos que almacenan sus bits en gráficos o en una serie de tiempo ofrecen nuevos paradigmas sobre cómo los programadores especifican lo que quieren encontrar.
No todas estas opciones serán mejores que SQL para lo que necesita hacer. No todos ellos captarán las posibilidades que está buscando. Pero todos ofrecen la oportunidad de pensar de manera diferente sobre ese mar de bytes en algún servidor, esperando que encuentres una manera de deletrear lo que necesitas.
GraphQL
El nombre de GraphQL es un poco confuso porque en realidad no es un lenguaje diseñado para explotar todas las posibilidades de las bases de datos de gráficos. Es más como una abreviatura elegante para consultar datos almacenados en un formato anidado similar a JSON. La consulta es solo una descripción rápida de cómo deberían ser los resultados. El back-end mira esta lista de campos, que pueden tener restricciones en los valores, e intenta encontrar los resultados que coinciden. Donde SQL especifica cómo la base de datos debe completar una solicitud, los usuarios de GraphQL simplemente proporcionan una lista de campos. Algunos lo llaman “consulta por ejemplo”.
El lenguaje es una combinación natural para algunas bases de datos JSON, pero GraphQL también se está volviendo más popular para buscar bases de datos relacionales con un esquema tabular. Los back-ends inteligentes pueden traducir las solicitudes anidadas en un patrón de JOIN que se ajuste al esquema.
El lenguaje original comenzó como un proyecto interno en Facebook, pero después de que se lanzó como un proyecto de código abierto independiente, otros comenzaron a desarrollar los back-ends de GraphQL. Ahora hay versiones escritas en todos los idiomas principales y también en muchos idiomas experimentales modernos.
PRQL
Si, naturalmente, piensa en el software como una canalización o un lenguaje ensamblador, es posible que le guste PRQL, que significa Lenguaje de consulta relacional canalizado (pronunciado “Precuela”). Las consultas en este lenguaje se estructuran como una cadena de pequeños comandos. En conjunto, los comandos producen un resultado con solo los datos que desea.
Al igual que muchos lenguajes de programación modernos, el modelo mental de una consulta adopta un enfoque funcional. Las características simples como las variables reducen la repetición y simplifican el flujo. Los resultados de una línea se alimentan a la siguiente línea en una larga cadena. Si desea eliminar un paso, a menudo puede simplemente comentar esa línea y el resto de la canalización seguirá funcionando.
El código de PRQL está escrito en Rust como transpilador para convertir PRQL en SQL. La estructura básica está destinada a ser extensible, por lo que puede agregar más abstracciones para adaptarse a su caso de uso. Esta facilidad de experimentación asegura que el lenguaje evolucionará rápidamente.
WebAssembly
Muchos desarrolladores piensan en WebAssembly (abreviado como Wasm) como una herramienta para crear aplicaciones rápidas que se ejecutan en navegadores web. Cuando Redpanda comenzó a crear una herramienta de transmisión de datos para reemplazar a Kafka, querían agregar un mecanismo no solo para entregar los datos, sino también para transformarlos ocasionalmente en el camino. WebAssembly fue su elección.
Redpanda actúa como un libro mayor al crear un flujo de datos que es inmutable y ordenado. Se agregan eventos y los programadores pueden acceder a la transmisión en cualquier momento en el pasado. La mayoría comenzará con eventos recién creados, pero algunos pueden comenzar en el pasado para crear agregaciones históricas.
WebAssembly, por supuesto, es mucho más capaz y de bajo nivel incluso que los procedimientos almacenados que forman parte de algunas bases de datos. No todos los desarrolladores quieren escribir un código de nivel de byte de bits. Pero la opción abre el flujo de datos para elaborar transformaciones que van mucho más allá de lo que es posible con SQL.
GQL
Graph Query Language, o GQL, es un estándar propuesto que combina lenguajes declarativos similares como Cypher, PGQL y GSQL. Los desarrolladores crean consultas especificando un modelo particular para un conjunto de nodos y luego la base de datos es responsable de encontrar coincidencias. GQL trabaja con gráficos de propiedades más complejos que permiten que pares de nodos compartan varias conexiones diferentes.
El estándar está en desarrollo activo. Actualmente, las mejores implementaciones son herramientas de investigación que no están diseñadas para una implementación a largo plazo.
Gremlin
Gremlin, uno de los lenguajes originales para buscar un gráfico, solicita un conjunto de pasos para buscar a través de las conexiones entre nodos. Algunos lo llaman un lenguaje “basado en rutas” o “recorrido de gráficos”. Cada consulta se basa en pasos, y cada paso puede implicar mapear el nodo actual, filtrar una lista o tabular el resultado de alguna manera.
El idioma es a menudo sólo un punto de partida. Algunos, por ejemplo, están expandiendo Gremlin incrustando un intérprete de Python en su interior para que las consultas puedan incluir código de Python. Otros están incorporando Gremlin dentro de un lenguaje de programación estándar como Java para que los programadores puedan aprovechar el poder de Gremlin desde dentro de ese lenguaje.
Gremlin se creó por primera vez para el proyecto TinkerPop de Apache y ha sido adoptado por las principales bases de datos de gráficos transaccionales como Neptune de Amazon y marcos de procesamiento de gráficos que utilizan Apache Spark o Hadoop.
N1QL
A lo largo de los años, Couchbase ha buscado la mejor manera de consultar documentos generales. Al principio, la consulta se escribía como una función de JavaScript que se entregaba a la base de datos para su ejecución. Era una buena solución general que a veces tardaba una eternidad en generar un resultado, pero requería que los programadores pensaran un poco diferente.
N1QL (pronunciado “nickel”) está diseñado para facilitar que los nativos de SQL trabajen con los objetos JSON que podrían almacenarse en Couchbase. Una consulta básica tiene varias secciones especificadas por las palabras clave SELECT, FROM y WHERE, al igual que SQL. Los detalles de especificar la ruta a la estructura de datos de la que provendrán los datos se ajustan y adaptan al mundo anidado de los objetos JSON.
Para fomentar la experimentación, N1QL ofrece un banco de trabajo de consulta con una interfaz visual para probar y refinar las consultas. Couchbase también ofrece una opción genérica de búsqueda de texto completo que se ejecuta de forma independiente para consultas que buscan palabras de texto en lugar de datos estructurados.
Malloy
El problema de SQL, según los creadores de Malloy, radica en los detalles sintácticos. Expresar incluso la consulta más simple lleva tiempo porque el lenguaje es detallado y está lleno de trampas de rendimiento ocultas. Entonces, crearon un lenguaje de programación moderno con valores predeterminados naturales y una sintaxis más simple que se puede compilar en SQL, por lo que nadie necesita actualizar una base de datos de valores.
El resultado es una sintaxis que se asemeja a un GraphQL más potente. Una consulta es más como un modelo o una visión del resultado, incluidas las restricciones, las coincidencias o los valores predeterminados. Malloy maneja algunas optimizaciones en segundo plano. Los JOIN más inteligentes, por ejemplo, se pueden generar automáticamente para evitar abismos y trampas en el rendimiento de los fanáticos. Las subconsultas se pueden agregar para ahorrar tiempo. También se agregan índices según sea necesario. Como resultado, escribir consultas se parece más a escribir código moderno, con puntuación que sirve para mantener la estructura sucinta.
El núcleo de código abierto de Malloy está construido en TypeScript para incluirlo en el código de Node.js. Un complemento de VS Code simplifica el desarrollo.
Base
La mayoría de los lenguajes de consulta están vinculados directamente a una base de datos en particular. La base es construir más de una canalización que pueda extraer de una variedad de fuentes antes de filtrarlas con una combinación de SQL y Python. Al final de la canalización están los exportadores que entregan los datos a una variedad de opciones estándar, que van desde código en ejecución hasta algoritmos de IA, gráficos y paneles.
Los desarrolladores ya están creando canalizaciones como esta en su propio código y muchos proyectos dependen de estructuras similares. Basis ofrece una opción preconstruida que se puede personalizar de formas más elaboradas. Las entradas van desde consultas de base de datos estándar hasta toques de API y código Python personalizado. Los transformadores no se limitan a las cláusulas WHERE básicas de SQL porque puede escribir código de Python que hace más que filtrar a medida que los datos fluyen por la canalización.
Basis es solo un ejemplo de las herramientas de canalización de datos más nuevas que están abriendo el proceso de consulta para extraer de más de una fuente, filtrar con más de un idioma y entregar los datos en más de una forma. Es una visión de poder tomar datos de casi cualquier fuente y entregarlos a casi cualquier consumidor.
Fuente: https://www.infoworld.com/article/3654909/beyond-sql-8-new-languages-for-data-querying.html
