Acadia y el futuro de los lenguajes de consulta relacionales
Things I want in a modern relational query language
Un desarrollador con experiencia en MySQL y Db2 reflexiona sobre las deficiencias de SQL y propone mejoras para un lenguaje de consulta moderno. Critica la sintaxis anticuada, los planificadores de consultas opacos y la falta de tipos definidos por el usuario, y aboga por la incorporación de técnicas de programación funcional como tipos suma, uniones discriminadas y coincidencia de patrones. El artículo incluye ejemplos concretos de cómo estas características podrían simplificar consultas complejas y reducir errores.
Un lenguaje que aprenda de SQL podría hacer que los datos relacionales sean más fáciles de manipular para los programadores.
- scythmic_waves
Hay cierto solapamiento con algunos de mis ensayos favoritos sobre por qué SQL es deficiente:
https://www.scattered-thoughts.net/writing/against-sql
Ese post en particular termina con una lista de deseos, por lo que es el más similar al artículo original. Pero hay otros en el sitio que disfruto bastante (haz clic en el icono de inicio y busca "SQL" en la página).
Mi opinión personal es que SQL seguirá reinando durante mucho tiempo debido a lo monumental que es la tarea de reemplazarlo, dada la complejidad inherente de las bases de datos. Los LLMs empeoran esto porque son muy buenos traduciendo prosa a SQL. Ahora que importa menos lo molesto que sea SQL para los programadores, SQL se volverá más como ensamblador con el tiempo: algo que principalmente escriben las computadoras porque es complicado para los humanos tratar directamente. Esto es profundamente irónico dado que SQL fue supuestamente diseñado para leerse como prosa, es decir, para ser fácil para los humanos.
- burakemir
Estaría genuinamente curioso de qué opinan el autor del artículo y la gente aquí sobre Mangle Datalog en este contexto. La implementación en Go está aquí: https://codeberg.org/TauCeti/mangle-go y la implementación en Rust está aquí: https://codeberg.org/TauCeti/mangle-rs
Las implementaciones no son de alto rendimiento, pero si puedes caber todo en memoria o puedes organizar tus datos e integrarlos a través de consultas externas, deberías obtener algo funcional para muchos casos de uso.
No me propuse reemplazar SQL, y aunque no me importa la adopción, no es por eso que lo comparto aquí. La liberación del código fuente fue motivada por hacer Datalog más conocido. Hice algunas investigaciones y descubrí que necesitaba una implementación de Datalog con características particulares; ciertamente sabía que no quería usar SQL para lo que necesitaba.
Hay tipos estructurados y recursión, y poder nombrar predicados y componer consultas... Mangle tiene algunos usuarios y hay algunas aplicaciones que aprovechan el enfoque de consultas-como-programación-lógica.
Creo que una idea que se puede extraer de esta discusión es que un lenguaje de consulta y el sistema (implementación del DBMS) del que forma parte difícilmente pueden separarse cuando se trata de los inevitables requisitos de rendimiento que uno tiene.
- bastawhiz
Como comentario meta, puedo manejar bloques de código sin resaltado de sintaxis, y puedo manejar bloques de código que se ajustan. Pero ambos juntos con comentarios largos se convierten en ruido de línea. Ya no hay ninguna señal visual útil para saber cómo leerlos. En mi teléfono, los bloques de código son simplemente imposibles de analizar de manera significativa.
- mcc1ane
https://www.geldata.com/blog/we-can-do-better-than-sql
(https://news.ycombinator.com/item?id=24106608, https://news.ycombinator.com/item?id=19871051)
- weitendorf
Suena mucho a Spark antes de que se volviera tan orientado a empresas. En mis tiempos escribíamos Scala para ejecutar nuestras consultas, y una vez que descubrimos cómo configurar nuestro compilador y entorno, ¡nos gustaba!
Últimamente me he estado metiendo en Postgres y me sorprendió mucho lo fácil que es introducir nuevos tipos/operadores/etc. a través de código C. No estoy hablando de dominios. Solo escribe algo de C y puedes tener el tipo que quieras. Realmente me desmitificó las "extensiones", de hecho creo que ese es un nombre activamente dañino (suena torpe, grosero, basado en mi experiencia lidiando con "extensiones" y "plugins" en otros lugares) para lo que esencialmente son solo tipos/funciones personalizados. Más gente debería intentar escribir sus propias extensiones de Postgres. ¡No es nada difícil!
He estado cocinando en este espacio por bastante tiempo (HDFS/spark, Apache Pinot, cosas propietarias, un ORM funcional experimental sobre SQLite). El mayor problema, creo, es la interfaz entre las capas de gestión/administración, aplicación y "consulta". Creo que algo como grpc/protoc (o de hecho la forma en que Spark usaba la JVM) es necesario para proporcionar abstracciones sin fugas e interfaces más programáticas/estructuradas desde la base de datos a sus clientes. Estoy feliz de compartir más, pero básicamente, la base de datos necesita volverse capaz de (meta-)análisis general con un sistema de tipos reflexivo, creo.
- mikewarot
Mi petición tiene 15 años[1], una extensión SQL en vivo. Permitir que una consulta sea una suscripción a una base de datos, de modo que cualquier actualización se transmita como deltas a un cliente que escucha. Hubo muchísimas veces en mi tiempo usando SQL donde la misma consulta se ejecuta una y otra vez, solo para obtener/manejar ese delta.
¿No sería mucho más eficiente trabajar de esa manera desde el principio?
[1] http://livesql.org/ <--- solo unos pocos párrafos de texto de 2011
- nylonstrung
PRQL es uno de los mejores intentos de un nuevo lenguaje de consulta en mi opinión
He estado trabajando en un lenguaje de consulta basado en Lean4 que compila a Substrait, creo que el poder que tiene con respecto a tipos y programación funcional podría mejorar bastante la ergonomía de SQL
- 3eb7988a1663
¿Alguien puede explicarme por qué los mensajes de error de SQL son tan malos? Rutinariamente tengo alguna consulta monstruosa donde el mensaje es efectivamente, "Sintaxis ilegal en algún lugar, tonto".