¿Por qué se conoce SQL como un lenguaje funcional / basado en relaciones?

Estamos aprendiendo que la mayoría de los idiomas se clasifican como uno de los dos, "basados ​​en relaciones" o "de alto nivel". Nunca he usado SQL antes, pero al leer su sintaxis parece más una sintaxis imperativa / de alto nivel que funcional / basada en relaciones (Lisp, Haskell).

O podría ser que mi interpretación de las notas de la conferencia de mi profesor es incorrecta ... pero definitivamente enumera SQL como uno de los lenguajes basados ​​en relaciones (en oposición al nivel alto), y equipara las funciones basadas en relaciones con las funcionales ... o tal vez es que no entiendo por qué el hecho de que SQL trata con bases de datos relacionales hace que un lenguaje funcional sea la forma en que debería implementarse. (¿y por qué 'basado en relaciones' equivale a 'funcional' al categorizar lenguajes de programación?)

Gracias :)

Estamos aprendiendo que la mayoría de los idiomas se clasifican como uno de los dos, "basados ​​en relaciones" o "de alto nivel".

Esos conceptos son ortogonales. "Basado en relaciones" significa que la semántica del lenguaje se basa en el concepto de una relación, es decir, una asociación de muchos a muchos entre dos conjuntos (las relaciones son la base matemática detrás de las tablas SQL). "Alto nivel" significa que el lenguaje contiene muchas abstracciones que ocultan gran parte de los detalles técnicos subyacentes (como ubicaciones de memoria, registros de CPU, acceso a disco, operaciones bit a bit, etc.). SQL está ciertamente basado en relaciones, ya que su objetivo principal es describir datos relacionales y operaciones sobre él. SQL también es bastante alto nivel; no proporciona ningún medio para acceder directamente a los bytes en el disco, y no le brinda ningún detalle sobre cómo almacena sus datos (al menos el SQL estándar no lo hace;

De hecho, hay muchos más ejes a lo largo de los cuales se pueden clasificar los lenguajes de programación (y datos); uno particularmente interesante es declarativo versus imperativo . Los lenguajes declarativos describen qué es algo ; Los lenguajes imperativos describen cómo hacer algo. La parte DDL de SQL es mayormente declarativa, a pesar de las palabras clave imperativas de aspecto (" CREATE TABLE", ' DROP DATABASE', etc.), e incluso la parte de manipulación de datos ( SELECT, UPDATE, INSERT, DELETE) todavía es bastante declarativa. Una propiedad muy interesante de SQL es que no está completa en Turing: no se puede escribir un bucle ilimitado en ANSI SQL estándar.

La programación funcional se centra en algunas ideas centrales:

• las funciones son ciudadanos de primera clase (es decir, pueden usarse como valores, como entradas para otras funciones y como salida de otras funciones)
• funciones de orden superior (funciones que operan en funciones o funciones que devuelven funciones)
• pureza (una función pura es aquella que no tiene efectos secundarios; una función pura no puede hacer ninguna E / S, no puede leer ni modificar ningún estado global, y no puede tomar argumentos de referencia no constantes. Las funciones puras son especialmente interesantes porque siempre produce la misma salida con las mismas entradas)

SQL ciertamente no gira en torno a las funciones como la herramienta principal para modelar cosas, pero sí acepta la idea de pureza: la misma consulta ejecutada en la misma base de datos producirá el mismo resultado cada vez (excepto para ordenar). Llamar a SQL un lenguaje 'funcional' es un poco difícil, aunque en mi opinión.

SQL no es imprescindible porque el proceso de CÓMO se resuelven las consultas y las relaciones no están definidas por el programador, sino por el compilador / optimizador / intérprete. SQL es un lenguaje declarativo : en SQL, declaras relaciones. Esto crea una estructura de datos (que de nuevo no se define físicamente con el lenguaje sino mediante su implementación) mediante inserciones, actualizaciones y eliminaciones.

El uso de las relaciones se realiza mediante consultas (sentencias SELECT), que son funcionales porque no tienen efectos secundarios.

Todo está envuelto alrededor del modelo relacional .

SQL no es realmente tanto lenguaje funcional como declarativo. Los lenguajes funcionales, en general, enfatizan el estilo declarativo sobre el imperativo para minimizar los efectos secundarios. Esto podría llevar a algunas personas a referirse a SQL como funcional, pero no es preciso. Es declarativo con elementos de procedimiento.

¿Es posible que tus notas estén codificadas?

Nunca he oído hablar de lenguajes de programación divididos entre "basados ​​en relaciones" y "de alto nivel". El nivel bajo / alto generalmente se usa para distinguir ensamblador y C de lenguajes que proporcionan soporte directo para estructuras más abstractas. Las relaciones son una estructura bastante abstracta, por lo que diría que cualquier cosa que las soporte es de alto nivel por definición.

El SQL puro generalmente se describe como un lenguaje declarativo, con algunos bits de procedimiento añadidos por los distintos proveedores. El hecho de que SQL no admita funciones como variables me parece que lo descalifica inmediatamente de ser un lenguaje funcional.

SQL es un lenguaje relacional basado en conjuntos que ha tenido funcionalidades procesales añadidas.

No sé si consideraría SQL funcional, sin embargo, tiene algunos aspectos de los lenguajes funcionales. Las variantes modernas de SQL (con los bits de procedimiento) definitivamente no son funcionales.

Creo que SQL es un azúcar sintáctico en torno al álgebra relacional + algo más. El álgebra relacional tiene mucho poder de los lenguajes funcionales, de hecho aprovecha las funciones de muy alto poder de expresión (selección, proyección, cambio de nombre, unión, unión, intersección ...). Pero hasta donde yo sé, el tratamiento básico del álgebra relacional generalmente no tiene equivalente al operador lambda, aunque puede extenderse con un operador de recursión de una manera fluida.

Creo que el álgebra de relaciones es más bien un lenguaje algebraico. SQL, con sus subconsultas, ha pasado del álgebra relacional pura a un estilo más funcional, pero sin un operador lambda, creo que no es un lenguaje funcional completo. No sé si podría extenderse a un lenguaje funcional completo sin problemas, no soy un experto en este campo. Haskell tiene algunas bibliotecas con el objetivo de lenguajes de bases de datos de muy alto nivel.

No conozco todas las sutilezas de lo que necesita para que un lenguaje sea calificado como funcional, pero SQL Server introdujo una forma muy interesante de trabajar con funciones. Una cláusula especial hace que las funciones puedan interactuar juntas en una consulta. Se llama Aplicar. Cuando le expliqué eso a un antiguo programador de APL, me dijo que existía una cláusula similar en APL para un objetivo similar. La cláusula Apply permite pasar un conjunto de atributos desde la fila de una tabla o la fila de la función de tabla como entrada a otra función. Dicho esto, impuse una restricción en el tipo de función de tabla para escribir para que se considere funcional. El debe declararse como en línea, lo que significa que se expresa como una sola instrucción select. Esto impone no tener variables. Estas consultas con mucha lógica se pueden escribir siempre que use expresiones de tabla comunes que luego permitan convertir las expresiones en columnas, un tipo de variable inmutable que se puede reutilizar en otro CTE. Al final, la función se convierte en una macro muy grande que libera al optimizador para optimizar la forma en que lo necesita. Lo único que le falta a la gente son algunos trucos simples para escribir lógica condicional y declarar algunos datos que apoyan la lógica en la consulta. Por último, algunas funciones que utilizan la cláusula over son necesarias para llevar los resultados como un valor utilizable en una fila desde otras filas, pero sería un poco largo trabajar aquí. Lo único que le falta a la gente son algunos trucos simples para escribir lógica condicional y declarar algunos datos que apoyan la lógica en la consulta. Por último, algunas funciones que utilizan la cláusula over son necesarias para llevar los resultados como un valor utilizable en una fila desde otras filas, pero sería un poco largo trabajar aquí. Lo único que le falta a la gente son algunos trucos simples para escribir lógica condicional y declarar algunos datos que apoyan la lógica en la consulta. Por último, algunas funciones que utilizan la cláusula over son necesarias para llevar los resultados como un valor utilizable en una fila desde otras filas, pero sería un poco largo trabajar aquí.