Comparando SQL y Prolog

(9)

Empecé a aprender Prolog y me pregunté sobre la diferencia teórica del lenguaje SQL.

Por ejemplo:

ambos son lenguajes declarativos
ambos admiten una base de datos de conocimiento impulsada por hechos
ambos admiten recuperación de datos con estilo de pregunta
ambos soportan dependencias funcionales

¿Algún punto más en común? ¿Alguna diferencia notable?

Creo que la principal diferencia es que Prolog es un lenguaje de consulta utilizado para unir patrones complicados con una base de datos de hechos simples. SQL, por otro lado, está limitado a las bases de datos relacionales.

Esto lo ayudará a comenzar: Programación en Prolog

Muy temprano, puedes leer esto:

Prolog, como lenguaje de programación, es un poco inusual. Se puede entender como un lenguaje de procedimiento estándar con dos propiedades inusuales. Es un lenguaje de procedimiento como Pascal o Algol. Uno programa en un lenguaje de procedimientos escribiendo procedimientos que llevan a cabo operaciones particulares. Uno especifica qué debe hacer un procedimiento al usar declaraciones primitivas e invocando otros procedimientos. Los procedimientos de Prolog solo tienen variables locales y toda la información que un procedimiento puede usar o producir debe pasar por sus argumentos.
C se puede ver como un lenguaje de procedimiento al pensar en usarlo sin funciones; es decir, todas las funciones devuelven el vacío, y la información se pasa hacia y desde las funciones solo a través de sus argumentos.
En Prolog, los procedimientos se llaman predicados. Los dos aspectos inusuales de Prolog son:
1. Prolog tiene variables de asignar una vez, y 2. Prolog no es determinista.

Disfrutar.

Hay muchas diferencias que creo que se vuelven claras cuando empiezas a usarlas. Recuerde que debido a los cambios en la terminología, algunas cosas que se llaman lo mismo en el pasado significan cosas muy diferentes ahora.

Visión general muy amplia de la diferencia.

Las sentencias de SQL funcionan en una base de datos relacional y consultan (solicitan) datos de esa base de datos, cambian a esos datos y los resultados se expresan exactamente en el lenguaje, mientras que en Prolog defines hechos y un motor lógico genera nuevos hechos basados en los existentes hechos. Los nuevos datos (hechos) se crean a través de la evaluación.

Ambos usan algo llamado consultas (pero funcionan de manera totalmente diferente) y ambos tienen datos (pero lo usan de manera diferente).

Los casos de uso para SQL y Prolog también son totalmente diferentes. Nunca tendría sentido almacenar una lista de direcciones en Prolog, mientras que eso es exactamente lo que SQL fue diseñado para hacer.

Simplemente ponga SQL se usa para acceder a un almacén de datos y Prolog es un evaluador de expresiones.

Solo algunos pensamientos:

SQL es un lenguaje de consulta para el acceso (quizás complejo arbitrario) a datos (relacionales), no es un lenguaje de programación.
Incluso si se trata SQL como lenguaje de programación, no es Turing completo. Apenas puedo imaginar la consulta sql que devuelva la suma de 1 a 100 (por ejemplo).
SQL es un lenguaje para acceder / manipular (DML) a bases de datos , donde Prolog es un lenguaje para trabajar con bases de conocimiento (y motor de resolución de reglas, de causa). Prácticamente Prolog no es más que simplemente unificación y retroceso .
Esto no dice sobre los dominios de aplicación de SQL y Prolog, que son de causa totalmente diferente: almacenamiento de datos eficiente (regular) y AI / cálculos simbólicos / análisis / sistemas expertos / solucionadores de restricciones / ... / mucho más.

La principal diferencia en mi opinión es que SQL recupera las filas de las tablas, es decir, de un conjunto finito de objetos instanciados que corresponden a las condiciones del filtro. Por otro lado, Prolog te brinda teóricamente todos los objetos instanciables que satisfacen las condiciones. Y mientras en Prolog también puede recuperar entidades de un conjunto finito, en SQL no puede obtener todos los valores de un conjunto teóricamente infinito.

La mayoría de las respuestas (anteriores) son un reflejo del hecho de que la mayoría de la gente no sabe qué es SQL (es una implementación de cálculo relacional) o qué significa eso (que es una forma de lógica de predicados). Las siguientes afirmaciones son ciertas tanto para Prolog como para SQL:

ambos son impulsados por la lógica
ambos pueden almacenar, expresar y usar relaciones (relaciones lógicas en Prolog)
ambos pueden almacenar y expresar condiciones lógicas complejas
ambos tienen hechos (datos en SQL) y pueden sacar conclusiones de esos hechos
ambos tienen consultas, que de hecho significan lo mismo
ambos tienen datos (hechos en Prolog) y los usan de manera similar
ambos son lenguajes de programación
ambos son turing-completos (aunque es algo difícil de acceder en ambos)
etcétera etcétera..

En general, las personas no conocen estas equivalencias entre ellos:

"Hechos" y "Datos" son lo mismo. Esto está directamente del documento original de Codd.
Una "relación" en la teoría relacional es lo mismo que una "tabla" en SQL, es lo mismo que una relación o función relacional en la lógica de predicados y es lo mismo que un conjunto de tuplas en la teoría de conjuntos
Una expresión de tabla alias (es decir, una Vista, etc.) en SQL es lo mismo que una Regla en Prolog.

Entonces, ¿cuáles son sus diferencias? Aunque operan en los mismos dominios conceptuales, sus enfoques se encuentran en direcciones completamente diferentes. En términos de Prolog, SQL es principalmente un motor de hechos y relaciones (conjunto), mientras que Prolog es principalmente un motor de reglas e inferencias. Cada uno puede hacer lo otro, de forma limitada, pero se vuelve cada vez más difícil incluso con pequeños incrementos de complejidad. Por ejemplo, puede hacer inferencias en SQL, pero es casi completamente de naturaleza manual y no se parece en nada a la inferencia directa automática de Prolog. Y sí, puede almacenar datos (hechos) en Prolog, pero no está diseñado para el "almacenamiento, recuperación, proyección y reducción de Trillones de filas con miles de usuarios simultáneos" que SQL tiene.

Además, SQL es principalmente un paradigma de lenguaje de servidor, mientras que Prolog es principalmente un paradigma de lenguaje de cliente.

Prolog y SQL se basan en la lógica de primer orden, pero las tablas SQL son relaciones binarias simples, mientras que los predicados Prolog son cláusulas Horn.

Este no es un punto teórico oscuro. Las relaciones binarias de SQL son declaraciones de hecho, de la forma:

f (A, B, C ... N)

Donde f es el nombre de la relación y A ... N sus variables. Las relaciones binarias de Prolog son implicaciones de la forma:

A <- B, C, D ... N

Donde A ... N son ellos mismos las cláusulas de Horn. Las relaciones SQL son una forma eficiente de describir datos. Las relaciones de Prolog describen relaciones complejas entre datos, ellos mismos almacenados como datos.

Es importante entender que en Prolog, no hay separación entre los datos y la operación. Los hechos, reglas y consultas de Prolog son todas las cláusulas de Horn, por lo tanto, datos, algo que se pierde en la traducción en la mayoría de los cursos universitarios. Prolog no es como C, sino que tiene hechos en lugar de variables y reglas en lugar de funciones. Por otro lado, SQL se parece mucho a Prolog sin las reglas o consultas.

Las consultas SQL también son predicados lógicos, pero las consultas SQL no se almacenan en la base de datos. Más bien, se usan para extraer conjuntos de datos de la base de datos de hechos. Puede almacenar una consulta como una fila de tabla en una base de datos SQL pero no podría ejecutarla en ese formulario.

Las consultas Prolog se almacenan en la base de datos como cualquier otro predicado Prolog, porque son como cualquier otro predicado Prolog. Las consultas son cláusulas Horn de la forma:

<- B, C, D ... N

Entonces las implicaciones con un precedente pero sin antecedente, por lo tanto siempre son falsas. Los hechos son cláusulas Horn con un antecedente pero sin precedente, de la forma:

A <-

Entonces siempre es verdad. Prolog prueba una consulta por refutación: si no puede encontrar un hecho (o regla) que lo pruebe, indicará que el objetivo es verdadero, ya que una consulta siempre es falsa. En el proceso, algunas variables están vinculadas para que se puedan construir conjuntos de resultados, al igual que SQL con las consultas SELECT.

Los DBMS de SQL modernos tienen características como los procedimientos almacenados y el lenguaje de control de flujo para que SQL se pueda usar para la inferencia (no es que quiera hacer inferencias en SQL). Prolog viene listo con un motor de inferencia sintonizado en su base de datos de cláusulas Horn, porque es una forma eficiente de hacer inferencias sobre bases de datos de hechos establecidos como relaciones binarias (y no, no solo porque es bonito).

La naturaleza homoicónica de Prolog (los datos son datos de operación) significa que se deben agregar nuevos datos a la base de datos, por lo tanto, al programa, porque la base de datos es el programa. Por lo tanto, cada vez que se agrega un hecho nuevo a su base de datos (generalmente utilizando assert / 1), se debe decompilar todo el programa. Este es un gran PITA y hace que Prolog sea ineficaz para almacenar grandes conjuntos de datos, aunque no hay ninguna razón por la cual tiene que ser ineficiente en la recuperación de datos y los sistemas Prolog usarán los mismos algoritmos que los sistemas SQL para ese propósito. SQL, por otro lado, es muy adecuado tanto para el almacenamiento como para la recuperación.

Finalmente, Prolog tiene algunas características que SQL simplemente no tiene, es decir, su unificación de patrones llamada unificación, negación como falla y elementos sintácticos que facilitan el procesamiento de la lista y la declaración de gramática (notación gramática de cláusula definida). Esos fueron solo un accidente feliz y fueron agregados principalmente al idioma porque estaban de moda en el momento en que se creó (gracias a LISP). SQL recibió consultas recursivas hace relativamente poco tiempo, por lo que Prolog ya no puede jactarse de eso.

Y, por supuesto, ambos idiomas son débiles en I / O y matemáticas, aunque al menos puedes hacer algo de aritmética en Prolog sin tener que quitarte el pelo todo el tiempo.

Entonces, realmente, Prolog y SQL son tan parecidos como C y Haskell. Ambos se basan en la misma abstracción raíz, la lógica de primer orden (como C y Haskell se basan en álgebra) pero las cosas se ponen muy diferentes bastante rápido después de eso. Además, desde el punto de vista del diseño del lenguaje, SQL tiende a fracturarse, con muchas características de lenguaje diferentes (pedicadas, consultas, lenguaje de manipulación de datos ...). El diseño de Prolog es extremadamente consistente, por lo que todo el lenguaje es solo predicados y algunos signos de puntuación.

Para mí, la diferencia más importante es esta: no me gusta el SQL, pero tengo que trabajar con él. Me encanta Prolog, pero no puedo usarlo en el trabajo. La vida es injusta :)

xonix, necesita más experiencia de desarrollo para decir si se puede hacer algo en sql o no.

A continuación hay al menos 2 soluciones para su serie fibo. Uno usa el Stored Procedure y el otro usa CTE . Elige tu opción.

MÉTODO 1

declare @a int, @b int, @c int, @i int, @N int = 10 select @a=0, @b=1, @i=0, @c=0 print @a print @b while @i < @N Begin set @c=@a+@b print @c set @i=@i+1 set @a=@b set @b=@c end

MÉTODO 2

WITH FibonacciNumbers (RecursionLevel, FibonacciNumber, NextNumber) AS ( -- Anchor member definition SELECT 0 AS RecursionLevel, 0 AS FibonacciNumber, 1 AS NextNumber UNION ALL -- Recursive member definition SELECT a.RecursionLevel + 1 AS RecursionLevel, a.NextNumber AS FibonacciNumber, a.FibonacciNumber + a.NextNumber AS NextNumber FROM FibonacciNumbers a WHERE a.RecursionLevel < 10 ) -- Statement that executes the CTE SELECT ''F'' + CAST( fn.RecursionLevel AS VARCHAR) AS FibonacciOrdinal, fn.FibonacciNumber, fn.NextNumber FROM FibonacciNumbers fn; GO

Estás en lo correcto: Prolog y SQL están teóricamente relacionados (preguntas específicamente sobre las diferencias teóricas ).

Quiero complementar la respuesta de RBarryYoung , ofreciéndole algunos consejos para comprender la conexión, de modo que tenga un punto de partida para estudiar y comprender los aspectos técnicos.

Prolog y SQL comparten un núcleo: cada consulta expresable en un subconjunto de Prolog se puede expresar en un subconjunto de SQL y viceversa , es decir, estos subconjuntos son lógicamente equivalentes.

Para entender cómo esto puede ser cierto, debe examinar en qué fundamentos teóricos se basan tanto Prolog como SQL:

SQL ¹ es una mezcla de diferentes partes, no siempre bien integradas, aparentemente de Algebra Relacional ( RA ) y Tuple Relational Calculus ( TRC ) ² y otras partes, no relacionadas con la lógica (es decir SUM, operadores AVG, ORDER BY, y así en).
RA es equivalente en potencia expresiva a TRC seguro (independiente del dominio) (esto se conoce como el teorema de Codd ).
RA es equivalente en potencia expresiva a Datalog seguro sin recursión y con negación (estratificada) .
Datalog puede considerarse un "subconjunto flexible" de Prolog ³ ; un "subconjunto suelto" en el sentido de que hay complicaciones con la semántica operacional de Prolog: "... el orden de las cláusulas es irrelevante en Datalog en contraste con Prolog, que depende del orden de las cláusulas para calcular el resultado de la llamada de consulta " ( citando de aquí ).

Por supuesto, algo fuera de estos subconjuntos necesita más esfuerzo de traducción.

No obstante, creo que la afirmación de que la equivalencia en el poder expresivo de los dos subconjuntos es más que un llamamiento a la equivalencia de Turing ⁴ cuando se considera la traducción de Prólogo a SQL.

Notas:

1) Lamentablemente, SQL se puede usar en contraste con los fundamentos teóricos de RDBMS ( álgebra-cálculo relacional ); por ejemplo, las tablas SQL no son necesariamente relaciones , como por RA, es decir, pueden estar sin una clave (primaria), por lo que se permiten filas duplicadas. Tales tablas no son conjuntos sino multisectos (también conocidos como bolsas) de tuplas. En ese contexto, todos los resultados teóricos para RA, donde las relaciones son conjuntos, no son necesariamente válidos.

2) Para una traducción de SQL a TRC, consulte Una nota sobre la traducción de SQL a tuple calculus , también aquí (documento de postscript) .

3) Para obtener más información sobre las diferencias entre Datalog y Prolog, consulte Lo que siempre quiso saber sobre Datalog (y nunca se atrevió a preguntar) (documento pdf - enlaces directamente a la página 6, encabezado H. Datalog y Prolog ).

4) Para el registro: RA (y por lo tanto sus equivalentes TRC seguros y Datalog seguro sin recurrencia) no se completa a propósito, para evitar consultas interminables.

Nota histórica: el álgebra relacional de Prolog y Codd se concibió en la misma época (finales de los 60 y principios de los 70) en diferentes contextos: Colmerauer concibió Prolog para el procesamiento del lenguaje natural y Codd concibió RA como una base teórica de DBMS relacional. Entonces, cualquier conexión teórica entre Prolog-Datalog-RA-SQL se estableció necesariamente a posteriori y está implícita en el hecho de que están todas basadas en cálculo de predicados de primer orden (también conocido como lógica de primer orden ).