Сравнение SQL и Пролога - PullRequest
62 голосов
/ 22 января 2010

Я начал изучать Пролог и удивляться теоретическому отличию от языка SQL.

Например:

  • оба являются декларативными языками
  • оба поддерживают базу знаний, основанную на фактах
  • оба поддерживают получение данных в стиле вопросов
  • оба поддерживают функциональные зависимости

Есть еще общие точки? Есть заметные различия?

Ответы [ 8 ]

77 голосов
/ 22 января 2010

Большинство (более ранних) ответов здесь являются отражением того факта, что большинство людей не знают, что такое SQL (реализация реляционного исчисления) или что это означает (что это форма логики предикатов). Следующие утверждения верны как для Пролога, так и для SQL:

  • они оба управляются логикой
  • они могут хранить, выражать и использовать отношения (логические отношения в Прологе)
  • они могут хранить и выражать сложные логические условия
  • они оба имеют факты (данные в SQL) и могут сделать выводы из этих фактов
  • у них обоих есть запросы, которые на самом деле означают одно и то же
  • они оба имеют данные (факты в Прологе) и используют их аналогично
  • оба языка программирования
  • они оба завершены по Тьюрингу (хотя в обоих из них это довольно сложно получить)
  • и т. Д. И т. Д.

Как правило, люди не знают об этих эквивалентностях между ними:

  1. «Факты» и «Данные» - это одно и то же. Это прямо из оригинальной статьи Кодда.
  2. «Отношение» в реляционной теории - это то же самое, что и «Таблица» в SQL, то же самое, что и «Реляция» или реляционная функция в логике предикатов, и то же самое, что набор кортежей в теории множеств
  3. Псевдоним-табличное выражение (т. Е. Представление и т. Д.) В SQL - это то же самое, что и правило в прологе.

Так в чем их различия? Хотя они работают в одних и тех же концептуальных областях, их фокусы находятся в совершенно разных направлениях. В терминах Prolog, SQL - это прежде всего движок фактов и отношений (набор), тогда как Prolog - это, прежде всего, движок правил и выводов. Каждый может делать другое в ограниченной степени, но это становится все труднее даже при небольшом увеличении сложности. Например, вы можете сделать вывод в SQL, но он почти полностью ручной, и совсем не похож на автоматический форвард-вывод Prolog. И да, вы можете хранить данные (факты) в Prolog, но они совсем не предназначены для «хранения, поиска, проецирования и сокращения триллионов строк с тысячами одновременных пользователей», которыми является SQL.

Кроме того, SQL - это прежде всего парадигма на языке сервера, а Prolog - это прежде всего парадигма на языке клиента.

43 голосов
/ 23 января 2010

Вы правы: Prolog и SQL теоретически связаны (вы спрашивали конкретно о теоретических различиях).

Я хочу дополнить ответ RBarryYoung , дав вам несколько советов, чтобы понять связь, чтобы у вас была отправная точка для изучения и понимания технических особенностей.

Пролог и SQL имеют общее ядро: каждый запрос, выражаемый в подмножестве Пролога, может быть выражен в подмножестве SQL и наоборот, , то есть эти подмножества логически эквивалентны.

Чтобы понять, как это может быть правдой, вам необходимо выяснить, на каких теоретических основах основаны и Пролог, и SQL:

Конечно, что-то из этих подмножеств требует больше усилий для перевода.

Тем не менее, я думаю, что утверждение о том, что эквивалентность в выразительной силе двух подмножеств больше, чем обращение к Эквивалентность Тьюринга 4 при рассмотрении Prolog-to -SQL перевод.

Примечания:

1) К сожалению, SQL можно использовать в отличие от теоретических основ РСУБД ( реляционные алгебра-исчисления ); например, таблицы SQL не обязательно являются отношениями - в соответствии с RA - то есть они могут быть без (первичного) ключа, поэтому допускаются повторяющиеся строки. Такие таблицы - не наборы, а мультимножеств (или сумки) кортежей. В этом контексте все теоретические результаты для RA, где отношения являются множествами, не обязательно действительны.

2) Для перевода с SQL на TRC см. Примечание по переводу SQL в исчисление кортежей , также здесь (postscript бумага) .

3) Подробнее о различиях между даталогом и прологом см. Что вы всегда хотели знать о даталоге (и никогда не осмеливались спрашивать) (pdf бумага - ссылки непосредственно на страницу 6, заголовок H. Datalog and Prolog ).

4) Для записи: RA (и, следовательно, их эквиваленты - безопасный TRC и безопасный Datalog без рекурсии) не является намеренно завершенным по Тьюрингу, чтобы избежать бесконечных запросов.

Историческая справка: Пролог и реляционная алгебра Кодда были задуманны примерно в одно и то же время (конец 60-х - начало 70-х годов) в разных контекстах - Колмерауэр задумал Пролог для обработки естественного языка, а Кодд рассматривал RA как теоретический основа реляционных СУБД. Таким образом, любая теоретическая связь между Prolog-Datalog-RA-SQL была обязательно установлена ​​ a posteriori и подразумевается в том факте, что все они основаны на исчислении предикатов первого порядка (он же логика первого порядка ).

20 голосов
/ 27 июля 2013

Пролог и SQL основаны на логике первого порядка, но таблицы SQL представляют собой простые бинарные отношения, тогда как предикаты Пролога являются предложениями Хорна.

Это не какой-то неясный теоретический момент. Бинарные отношения SQL являются констатацией факта в форме:

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

Где f - имя отношения, а A ... N - его переменные. Прологические бинарные отношения являются следствиями вида:

A <- B, C, D ... N </em>

Где A ... N сами по себе являются клаузлами Рога. Отношения SQL - эффективный способ описания данных. Пролог отношения описывают сложные отношения между данными, которые сами хранятся в виде данных.

Важно понимать, что в Прологе нет разделения между данными и операциями. Факты, правила и запросы пролога - все это клаузлы Рога, поэтому данные - это то, что теряется при переводе в большинстве университетских курсов. Пролог не похож на C, но с фактами вместо переменных и правилами вместо функций. С другой стороны, SQL во многом похож на Prolog без правил или запросов.

SQL-запросы также являются логическими предикатами, но SQL-запросы не хранятся в самой базе данных. Скорее они используются для извлечения наборов данных из базы данных фактов. Вы можете сохранить запрос в виде строки таблицы в базе данных SQL, но не сможете выполнить его в этой форме.

Запросы Пролога хранятся в базе данных, как и любой другой предикат Пролога, потому что они похожи на любой другой предикат Пролога. Запросы - это роговые предложения вида:

<- B, C, D ... N </em>

Так что последствия с прецедентом, но без предшествующего, поэтому всегда ложные. Факты являются клаузлами Рога с предшествующим, но не прецедентным, видом:

A <- </em>

Так всегда и правда. Пролог подтверждает запрос путем опровержения: если он не может найти факт (или правило), подтверждающий его, он сообщит, что цель истинна, поскольку запрос всегда ложен. В этом процессе некоторые переменные связываются, поэтому наборы результатов могут быть сконструированы так же, как SQL это делает с запросами SELECT.

Современные СУБД SQL имеют такие функции, как хранимые процедуры и язык управления потоком, поэтому SQL можно использовать для вывода (не то, что вы хотите сделать вывод в SQL). Prolog поставляется с механизмом вывода, настроенным на его базу данных предложений Хорна, потому что это эффективный способ сделать вывод из баз данных фактов, представленных как бинарные отношения (и нет, не только потому, что это красиво).

Гомо-природа Prolog (данные - это операция - данные) означает, что новые новые данные должны быть добавлены в базу данных, следовательно, в программу, потому что база данных - это программа. Таким образом, каждый раз, когда новый факт добавляется в его базу данных (обычно с использованием assert / 1), вся программа должна быть декомпилирована. Это огромный PITA и делает Prolog неэффективным для хранения больших наборов данных, хотя нет никаких причин, по которым он должен быть неэффективным для данных извлечение , и системы Prolog будут использовать для этой цели те же алгоритмы, что и системы SQL. С другой стороны, SQL хорошо подходит как для хранения, так и для извлечения.

Наконец, у Пролога есть несколько функций, которых у SQL просто нет, а именно: супер-сопоставление с паттернами, называемое объединением, отрицание как сбой, и синтаксические элементы, которые облегчают обработку списка и объявление грамматики (нотация грамматики для определенных разделов). Это просто счастливый случай, и в основном они были добавлены к языку, потому что они были в моде во время его создания (благодаря LISP). SQL получил рекурсивные запросы относительно недавно, поэтому Prolog не может этим похвастаться.

И, конечно, оба языка слабы при вводе / выводе и по математике, хотя, по крайней мере, вы можете сделать некоторую арифметику в Прологе, не вырывая свои волосы все .

Итак, действительно, Prolog и SQL так похожи, как C и Haskell. Они оба основаны на одной и той же корневой абстракции, логике первого порядка (как C и Haskell основаны на алгебре), но после этого все очень быстро меняется. Кроме того, с точки зрения языкового дизайна, SQL имеет тенденцию к расколу со многими различными языковыми функциями (педикаты, запросы, язык манипулирования данными ...). Конструкция Пролога чрезвычайно последовательна, так что весь язык на самом деле представляет собой только предикаты и несколько знаков препинания.

Для меня самое важное отличие заключается в следующем: мне не нравится SQL, но я должен с ним работать. Я люблю Пролог, но я не могу использовать его на работе. Жизнь несправедлива:)

7 голосов
/ 16 мая 2011

Основным отличием моих глаз является то, что SQL извлекает строки из таблиц, то есть из конечного набора экземпляров объектов, соответствующих определенным условиям фильтра. С другой стороны, Prolog дает вам теоретически все экземпляры, которые удовлетворяют условиям. И хотя в Прологе вы также можете извлекать сущности из конечного набора, в SQL вы не можете извлечь все значения из теоретически бесконечного множества.

6 голосов
/ 22 января 2010

Есть много различий, которые, я думаю, станут понятны, когда вы начнете их использовать. Помните, что из-за изменений в терминологии некоторые вещи, которые в прошлом назывались одним и тем же, означают совсем другие вещи.

Очень широкий обзор различий.

Операторы SQL работают с реляционной базой данных и запрашивают (запрашивают) данные из этой базы данных, изменения в этих данных и результаты точно выражаются на языке, тогда как в Prolog вы определяете факты, а логический механизм генерирует новые факты на основе из существующих фактов. Новые данные (факты) создаются с помощью оценки.

Они оба используют то, что называется запросами (но они работают совершенно по-разному), и у них обоих есть данные (но используют их по-разному).

Варианты использования для SQL и Prolog также совершенно разные. Никогда не имеет смысла хранить список адресов в Прологе, тогда как именно для этого и предназначен SQL.

Проще говоря, SQL используется для доступа к хранилищу данных, а Prolog - это средство оценки выражений.

2 голосов
/ 22 января 2010

Я думаю, что основное отличие состоит в том, что Пролог - это язык запросов, используемый для сопоставления сложных шаблонов с базой данных простых фактов. SQL, с другой стороны, ограничен реляционными базами данных.

0 голосов
/ 15 мая 2017

xonix, вам нужно больше опыта разработки, чтобы сказать, можно ли что-то сделать в SQL или нет.

Ниже приведены как минимум 2 решения для вашей серии FIBO. Один использует Stored Procedure, а другой - CTE. Выбирай.

МЕТОД 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

МЕТОД 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
0 голосов
/ 22 января 2010

Всего несколько мыслей:

  1. SQL - это язык запросов для (возможно, произвольно сложного) доступа к (реляционным) данным, это не язык программирования.
  2. Даже если рассматривать SQL как язык программирования - он не завершен по Тьюрингу. Я с трудом представляю себе SQL-запрос, возвращающий сумму от 1 до 100 (например).
  3. SQL - это язык для доступа / манипулирования (DML) к базам данных , где Prolog - это язык для работы с базами знаний (и механизмом разрешения правил причины). Практически Пролог - это не более чем просто объединение & возврат .
  4. Это не относится к областям применения SQL и Prolog, которые имеют совершенно разные причины - эффективное (регулярное) хранение данных и ИИ / символьные вычисления / синтаксический анализ / экспертные системы / решатели ограничений /.../ и многое другое.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...