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

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

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

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

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

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

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

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

Вы также можете захотеть проверить GDAL Wiki, посвященный привязанию к Python - GDalogrinPython , где обсуждается установка и использование на платформах Linux и Windows.

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

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

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

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

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

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

• SQL ¹ представляет собой смесь различных частей, не всегда хорошо интегрированных, очевидно из реляционной алгебры ( RA ) и реляционного исчисления кортежей ( TRC ) ² и других частей, не связанных с логикой (например, SUM , Операторы AVG, ORDER BY и т. Д.).
• RA эквивалентен по выразительной способности безопасному (независимому от домена) TRC (это известно как теорема Кодда ).
• RA эквивалентен по выразительной мощности безопасному Datalog без рекурсии и с (стратифицированным) отрицанием .
• Datalog можно рассматривать как «свободное подмножество» Prolog ³ ; «слабое подмножество» в том смысле, что с ним связаны сложности. операционная семантика Пролога: " ..порядок предложений не имеет значения в Datalog, в отличие от Prolog, который зависит от порядка предложений для вычисления результата вызова запроса »( цитируется отсюда ).

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

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

Примечания:

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

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

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

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

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