Я начал изучать Prolog и размышлял над теоретическим отличием от языка SQL.
Например:
Какие-нибудь более общие точки? Какие-либо заметные отличия?
Большинство (более ранних) ответов здесь отражают тот факт, что большинство людей не знают, что такое SQL (его реализация Relational Calculus) или что это значит (что это форма Predicate Logic). Следующие утверждения справедливы как для Prolog, так и для SQL:
Как правило, люди не знают об этих эквивалентах между ними:
Так в чем их отличия? Хотя они работают в одних и тех же концептуальных областях, их фокусы находятся в совершенно разных направлениях. В терминах Prolog SQL - это, прежде всего, механизм Fact and Relation (set), тогда как Prolog - это в основном механизм правил и выводов. Каждый из них может сделать в ограниченной степени, но становится все труднее даже с небольшим увеличением сложности. Например, вы можете делать вывод в SQL, но он почти полностью ручен в природе и совсем не похож на автоматическую переадресацию Prolog. И да, вы можете хранить данные (факты) в Prolog, но это вовсе не предназначено для "хранения, поиска, проецирования и сокращения триллионов строк с тысячами одновременных пользователей", что SQL.
Кроме того, SQL - это прежде всего парадигма на языке сервера, тогда как Prolog - это прежде всего парадигма языка клиента.
Вы правы: Пролог и SQL теоретически связаны (вы задали вопрос о теоретических различиях).
Я хочу дополнить ответ RBarryYoung, давая вам несколько советов, чтобы понять связь, так что у вас есть отправная точка для изучения и понимания технических аспектов.
Prolog и SQL совместно используют ядро: каждый запрос, выражаемый в подмножестве Prolog, может быть выражен в подмножестве SQL и наоборот, т.е. эти подмножества логически эквивалентны.
Чтобы понять, как это может быть правдой, вам нужно изучить, на каких теоретических основах основываются как Prolog, так и SQL:
Конечно, что-то из этих подмножеств требует больше усилий по переводу.
Тем не менее, я считаю утверждение, что эквивалентность в выразительной силе двух подмножеств - это больше, чем призыв к эквивалентность Тьюринга 4 при переходе на преобразование Prolog-to-SQL.
Примечания:
1) К сожалению, SQL может использоваться в отличие от теоретических основ РСУБД (реляционных алгебр-исчислений); например, SQL-таблицы не обязательно отношения - согласно RA - то есть они могут быть без (первичного) ключа, поэтому допускаются дубликаты строк, Такие таблицы не являются наборами, но multisets (aka bags) кортежей. В таком контексте все теоретические результаты для RA, где отношения являются множествами, не обязательно действительны.
2). Для перевода с SQL на TRC см. Заметка о переводе SQL на кортеж исчисления, также здесь (постскриптум).
3) Подробнее о различиях между Datalog и Prolog см. Что вы всегда хотели знать о Datalog (и Never Dared для запроса) (pdf-документ - ссылки непосредственно на страницу 6, заголовок H. Datalog и Prolog).
4). Для записи: RA (и, таким образом, их эквиваленты, безопасные TRC и безопасный Datalog без рекурсии), не Тьюринг закончен целенаправленно, чтобы избежать бесконечного завершения запросы.
Историческая справка: Пролог и реляционная алгебра Codd были задуманы примерно в то же время (конец 60-х - 70-х годов) в разных контекстах - Colmerauer задумал Prolog для обработки естественного языка, а Codd задумал RA как теоретическая основа реляционной СУБД. Таким образом, любая теоретическая связь между Prolog-Datalog-RA-SQL была обязательно установлена апостериорной и подразумевается в том, что все они основаны на исчислении предикатов первого порядка (aka логика первого порядка).
Prolog и SQL основаны на логике первого порядка, но таблицы SQL - это простые двоичные отношения, тогда как предикаты Prolog - предложения Horn.
Это не какой-то неясный теоретический момент. SQL-двоичные отношения - это утверждения факта, формы:
f (A, B, C... N)
Где f - это имя отношения, а A... N - его переменные. Бинарные отношения Prolog являются следствиями формы:
A < -B, C, D... N
Где A... N сами являются предложениями Хорна. SQL-отношения - эффективный способ описания данных. Соотношения Prolog описывают сложные отношения между данными, которые сами хранятся как данные.
Важно понимать, что в Prolog нет разделения данных и операций. Факты, правила и запросы Пролога - это все предложения Хорна, поэтому данные, которые теряются в переводе на большинстве университетских курсов. Пролог не похож на C, а на факты вместо переменных и правил вместо функций. С другой стороны, SQL очень похож на Prolog без правил или запросов.
SQL-запросы также являются логическими предикатами, но SQL-запросы не хранятся в самой базе данных. Скорее, они используются для извлечения наборов данных из базы данных фактов. Вы можете сохранить запрос в виде строки таблицы в базе данных SQL, но вы не сможете выполнить его в этой форме.
Запросы Prolog хранятся в базе данных, как и любой другой предикат Prolog, потому что они похожи на любой другой предикат Prolog. Запросы представляют собой предложения Хорна формы:
< -B, C, D... N
Таким образом, последствия с прецедентом, но не антецеденты, поэтому всегда ложны. Факты - это предложения Хорна с антецедентом, но не прецедент, формы:
A < -
Так всегда верно. Prolog доказывает запрос путем опровержения: если он не может найти факт (или правило), который его докажет, он заявит, что цель верна, поскольку запрос всегда является ложным. При этом некоторые переменные привязаны, поэтому могут создаваться наборы результатов, подобно тому, как SQL выполняет запросы SELECT.
Современные СУБД SQL имеют такие функции, как хранимые процедуры и язык управления потоками, поэтому SQL можно использовать для вывода (не для того, чтобы вы делали вывод в SQL). Prolog поставляется с механизмом вывода, настроенным на его базу данных предложений Horn, потому что это эффективный способ сделать вывод о базах данных фактов, заявленных как двоичные отношения (и нет, не только потому, что это довольно).
Гологозвуковая природа Пролога (данные - это данные) означает, что новые новые данные должны быть добавлены в базу данных, поэтому в программу, потому что база данных является программой. Поэтому каждый раз, когда в базу данных добавляется новый факт (обычно используя assert/1), вся программа должна быть декомпилирована. Это огромный PITA и делает Prolog неэффективным для хранения больших наборов данных, хотя нет никаких причин, по которым он неэффективен при извлечении данных, и системы Prolog будут использовать те же алгоритмы, что и системы SQL для этой цели. SQL, с другой стороны, хорошо подходит для хранения и поиска.
Наконец, у Prolog есть несколько функций, которые SQL просто не имеет, а именно его супер-шаблонное совпадение, называемое унификацией, отрицание как провал и синтаксические элементы, которые облегчают обработку списка и декларацию грамматики (обозначение грамматики определенной позиции). Это просто счастливая случайность и в основном были добавлены к языку, потому что они были в моде во время его создания (благодаря LISP). SQL получил рекурсивные запросы относительно недавно, поэтому Prolog не может похвастаться этим больше.
И, конечно, оба языка слабы в I/O и математике, хотя, по крайней мере, вы можете сделать некоторую арифметику в Prolog без необходимости вытягивать свои волосы на всем пути.
Итак, действительно, Prolog и SQL так же похожи, как C и Haskell. Они оба основаны на одной и той же корневой абстракции, логика первого порядка (например, C и Haskell основаны на алгебре), но после этого все становится очень по-разному. Кроме того, с точки зрения языкового дизайна, SQL имеет тенденцию к разрыву, с множеством различных языковых особенностей (педикаты, запросы, язык манипулирования данными...). Дизайн Prolog чрезвычайно последователен, так что весь язык на самом деле просто предикаты и несколько знаков препинания.
Для меня самое важное отличие заключается в следующем: мне не нравится SQL, но мне нужно работать с ним. Мне нравится Пролог, но я не могу использовать его на работе. Жизнь несправедлива:)
Основное отличие в моих глазах заключается в том, что SQL извлекает строки из таблиц, т.е. из конечного набора экземпляров объектов, соответствующих условиям фильтра сертификации. С другой стороны, Prolog дает теоретически все объекты, удовлетворяющие условиям. И хотя в Prolog вы также можете извлекать объекты из конечного набора, в SQL вы не можете получить все значения из теоретически бесконечного набора.
Есть много различий, которые, как мне кажется, становятся ясными, когда вы начинаете их использовать. Помните, из-за изменений в терминологии, что-то, что называется в прошлом, означает совсем другое.
Очень широкий обзор различий.
Операторы SQL работают с реляционной базой данных и запрашивают (запрашивают) данные из этой базы данных, изменяют эти данные, а результаты точно выражаются на языке, тогда как в Prolog вы определяете факты, а логический движок генерирует новые факты, основанные на из существующих фактов. Новые данные (факты) создаются путем оценки.
Они используют то, что называется запросами (но они работают совершенно по-другому), и оба они имеют данные (но используют их по-другому.)
Варианты использования для SQL и Prolog также совершенно разные. Было бы бессмысленно хранить список адресов в Prolog, но это именно то, что было разработано SQL.
Проще говоря, SQL используется для доступа к хранилищу данных, а Prolog - оценщик выражений.
Я думаю, что основное отличие состоит в том, что Prolog - это язык запросов, используемый для сопоставления сложных шаблонов с базой данных простых фактов. SQL, с другой стороны, ограничивается реляционными базами данных.
Это поможет вам начать: Программирование в Prolog
Очень скоро вы можете прочитать это:
Prolog, как язык программирования, является немного необычный. Это можно понять как стандартный процедурный язык с два необычных свойства. Это процедурный язык, такой как Pascal или Алголь. Одна программа в процедурной языка путем написания процедур, которые выполнять конкретные операции. Один определяет процедуру, которую используя примитивные утверждения и ссылаясь на другие процедуры. пролог процедуры имеют только локальные переменные и всю информацию о том, что процедура может быть использована или прошел через свои аргументы.
C можно рассматривать как процедурный язык, думая об использовании его без функций; т.е. все функции return void, и информация передается до и от функций через их только аргументы.
В Prolog процедуры называются предикаты. Два необычных аспекта Пролог:
1. Пролог имеет переменные с однократным назначением и 2. Пролог недетерминирован.
Enjoy.
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 @[email protected][email protected]
print @c
set @[email protected]+1
set @[email protected]
set @[email protected]
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
Несколько мыслей: