Сравнение SQL и пролога

вы правы: Пролог и SQL теоретически связаны (вы спрашивали конкретно о теоретической различия).

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

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

чтобы понять, как это может быть правдой, вам нужно изучить, на чем основаны теоретические основы как Prolog, так и SQL:

• SQL¹ представляет собой смесь различных частей, не всегда хорошо интегрированных,видимо от Реляционная Алгебра (РА) и кортеж реляционного исчисления ( TRC)² и другие части, не связанные с логикой (т. е. сумма, операторы AVG, ORDER BY и т. д.).
• РА эквивалентно по выразительной силе безопасное (домен-независимый) TRC (это называется теорема Кодда).
• РА эквивалентно по выразительной силе безопасное Регистрация без рекурсии и с (стратифицированной) отрицание.
• Регистрация можно считать "свободная подмножество"Пролог³; "свободное подмножество" в том смысле, что есть осложнения w.r.t. операционная семантика пролога: "..порядок предложений не имеет значения в Datalog в отличие от пролога, который зависит от порядка предложений для вычисления результата вызова запроса" (цитировать здесь).

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

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

Примечания:

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

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

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

4) Для справки: РА (и поэтому их эквиваленты безопасны TRC и safe Datalog без рекурсии) не является полным Тьюрингом специально, чтобы избежать бесконечных запросов.

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

Prolog и SQL основаны на логике первого порядка, но таблицы SQL-это простые двоичные отношения, тогда как предикаты Prolog-это предложения Horn.

Это не какой-то непонятный теоретический момент. Двоичные отношения SQL-это утверждения факта, вида:

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

здесь f это имя отношения и A...N ее переменных. Пролог бинарные отношения являются следствиями, из форма:

A

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

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

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

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

таким образом, последствия с прецедентом, но без антецедента, поэтому всегда ложны. Факты-это роговые предложения с антецедентом, но без прецедента, формы:

A

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

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

гомоиконическая природа Prolog (data is operation is data) означает, что новые новые данные должны быть добавлены в базу данных, следовательно, в программу, потому что база данных является программой. Поэтому каждый раз, когда новый факт добавляется в свою базу данных (обычно с помощью assert/1), вся программа должна быть декомпилирована. Это огромный Пита и делает Пролог неэффективным для хранения больших наборы данных, хотя нет никаких причин, почему он должен быть неэффективным в data поиска и пролог системы будут использовать те же алгоритмы, что и системы SQL для этой цели. SQL, с другой стороны, хорошо подходит как для хранения, так и для извлечения.

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

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

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

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

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

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

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

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

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

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

проще говоря SQL используется для доступ к хранилищу данных и пролог является вычислителем выражений.

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

Это поможет вам начать: программирование на языке Пролог

очень рано, вы можете прочитать это:

Пролог как язык программирования немного необычно. Это можно понять как стандартный процедурный язык с два необычных свойства. Это процедурный язык, как Паскаль или АЛГОЛ. Одна программа в процедурном язык путем написания процедур, которые выполняйте определенные операции. Один указывает, что должна делать процедура от использование примитивных операторов и по вызов других процедур. Пролог процедуры имеют только локальные переменные и всю информацию, что процедура может использовать или произвести должна быть прошел через его аргументы.

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

в прологе процедуры называются предикаты. Два необычных аспекта Пролог являются:

1. Пролог имеет присвоить один раз переменные, и 2. Пролог является недетерминированным.

наслаждайтесь.

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

Ниже приведены по крайней мере 2 решения для вашей серии Фибо. С помощью 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

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

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