que - Además de un lenguaje declarativo, ¿SQL es un lenguaje funcional?
que es sql y para que sirve (8)
¿Por qué sí o por qué no?
¿Declarativo y funcional? Eso sería una hoja de cálculo.
¿Las funciones son objetos de primera clase en SQL? apenas. Entonces yo diría que no.
Como el objetivo de un lenguaje funcional es que programes con, bueno, funciones, diría que no. SQL está programando con relaciones (si puede incluso llamar a SQL un lenguaje de programación, en su forma básica, SQL no está completo).
Creo que SQL y los lenguajes funcionales son muy diferentes entre sí. En un lenguaje funcional, el cálculo se realiza evaluando funciones. Las funciones no mutan el estado. Todo lo que hacen es calcular un valor a partir de sus argumentos. En otras palabras, las funciones no causan efectos secundarios. Los lenguajes funcionales son de propósito general.
SQL es un lenguaje diseñado para tratar con sistemas de administración de bases de datos relacionales. Se puede ver como un lenguaje específico del dominio. Está diseñado para trabajar en "conjuntos" de datos. Puede mutar el estado global (es decir, la base de datos) usando comandos como ACTUALIZAR. No existe el concepto de que las funciones se evalúen con un valor. Por lo que yo entiendo, SQL ni siquiera está completo.
En términos generales, como sin extensiones a la sintaxis (por ejemplo, PL / SQL, T-SQL), no puede escribir funciones.
Pero ciertamente está muy orientado a la expresión, que es una característica que tiene en común con los lenguajes funcionales.
No existe una única definición verdadera de lo que es un lenguaje funcional (o para el caso, lo que es un procedimiento u orientado a objetos).
Pero realmente no puedo pensar mucho de que el SQL sea funcional. No tiene funciones, no tiene recursión, no tiene cierres, no tiene funciones anidadas, no tiene funciones como tipos de primera clase.
Una pregunta más común es si SQL es un lenguaje de programación. No es turing-completo.
No, SQL no es un lenguaje funcional. El paradigma es algo diferente. Tenga en cuenta que hay otros tipos de lenguajes de programación declarativa además de funcional: el ejemplo canónico es la programación lógica y PROLOG.
Técnicamente, el álgebra relacional (la base teórica de SQL) no está realmente completa. Aunque los dialectos de SQL modernos añaden suficientes características de procedimiento para que uno pueda implementar procedimientos almacenados y estén completos en este nivel, una única consulta de SQL no es un cálculo completo. Relational Algebra tiene la propiedad de completar godel. La integridad de Godel implica la capacidad de expresar cualquier cálculo que pueda definirse en términos de cálculo de predicados de primer orden, básicamente lo que usted conocería como expresiones lógicas ordinarias.
SQL fue diseñado como un lenguaje declarativo, en el sentido de que usted dice what que quiere obtener y el motor SQL decide how hacerlo.
Sin embargo, SQL opera en conjuntos, y los resultados de las funciones pueden ser conjuntos de primera clase en Oracle , SQL Server y PostgreSQL .
Se puede decir que SQL es un lenguaje funcional, siempre que una función tome como entrada un conjunto y produzca un conjunto como salida.
Es decir, puedes escribir algo como esto:
SELECT *
FROM mytable t
JOIN myfunction(x) f
ON f.col1 = t.col2
, o incluso esto:
SELECT *
FROM mytable t
CROSS APPLY
myfunction(t.col2) f
(en SQL Server )
o esto:
SELECT t.*, myfunction(t.col2)
FROM mytable t
(en PostgreSQL )
Aunque esto no forma parte del estándar SQL .
Al igual que un compilador de C++ trata de encontrar una forma óptima de multiplicar dos float (en términos de álgebra simple), el optimizador de SQL trata de encontrar una forma óptima de multiplicar dos conjuntos (en términos de álgebra relacional).
En C++ , simplemente escribe a * b confía en el compilador para generar un ensamblaje óptimo para esto.
En SQL , escribe SELECT * FROM a NATURAL JOIN b y confía en el optimizador.
Sin embargo, con todas SQL declaratividades declaradas de SQL (sin juego de palabras), la mayoría de los optimizadores reales solo pueden hacer reescrituras de consultas muy básicas.
Digamos que ningún optimizador que conozco es capaz de usar el mismo plan eficiente para esta consulta:
SELECT t1.id, t1.value, SUM(t2.value)
FROM mytable t1
JOIN mytable t2
ON t2.id <= t1.id
GROUP BY
t1.id, t1.value
y para este:
SELECT id, value, SUM(t1.value) OVER (ORDER BY id)
FROM mytable
, para no decir nada de consultas más complejas.
Es por eso que todavía necesita formular sus consultas para que usen un plan eficiente (mientras siguen produciendo el mismo resultado), lo que hace SQL un poco menos de un lenguaje declarativo.
Recientemente hice una publicación en mi blog sobre esto: