SQL과 프롤로그 비교

SQL과 프롤로그 비교

---

저는 Prolog를 배우기 시작했고 SQL 언어와의 이론적 차이에 대해 궁금해했습니다.

예를 들면 :

• 둘 다 선언적 언어입니다.
• 둘 다 사실 기반 지식 데이터베이스를 지원합니다.
• 둘 다 질문 스타일의 데이터 검색을 지원합니다.
• 둘 다 기능적 종속성을 지원합니다.

더 많은 공통점은? 눈에 띄는 차이점이 있습니까?

---

여기에있는 대부분의 (이전) 답변은 대부분의 사람들이 SQL이 무엇인지 (관계형 미적분의 구현) 또는 그것이 의미하는 바 (Predicate Logic의 한 형태)를 모른다는 사실을 반영한 것입니다. 다음 명령문은 Prolog 및 SQL 모두에 해당됩니다.

• 둘 다 논리 중심입니다.
• 관계 (Prolog의 논리적 관계)를 저장, 표현 및 사용할 수 있습니다.
• 복잡한 논리적 조건을 저장하고 표현할 수 있습니다.
• 둘 다 사실 (SQL의 데이터)을 가지고 있으며 그 사실로부터 결론을 도출 할 수 있습니다.
• 둘 다 쿼리가 있습니다. 실제로는 같은 의미입니다.
• 둘 다 데이터 (Prolog의 사실)를 가지고 있으며 유사하게 사용합니다.
• 둘 다 프로그래밍 언어입니다.
• 둘 다 튜링이 완료되었습니다 (둘 다 접근하기가 다소 어렵지만)
• 기타 등등 ..

일반적으로 사람들은 다음과 같은 동등성을 인식하지 못합니다.

1. "사실"과 "데이터"는 동일합니다. 이것은 Codd의 원본 논문에서 바로 나온 것입니다.
2. Relational Theory의 "Relation"은 SQL의 "Table"과 동일하고 Predicate Logic의 Relation 또는 관계 함수와 동일하며 Set Theory의 튜플 세트와 동일합니다.
3. SQL의 별칭 테이블 표현식 (예 : View 등)은 Prolog의 규칙과 동일합니다.

그렇다면 그들의 차이점은 무엇입니까? 동일한 개념 영역에서 작동하지만 초점은 완전히 다른 방향입니다. Prolog 용어에서 SQL은 주로 Fact and Relation (set) 엔진 인 반면 Prolog는 주로 Rules 및 Inferencing 엔진입니다. 각각은 제한된 범위에서 서로를 할 수 있지만 복잡성이 조금만 증가해도 점점 어려워집니다. 예를 들어 SQL에서 추론을 수행 할 수 있지만 사실상 거의 완전히 수동이며 Prolog의 자동 순방향 추론과는 전혀 다릅니다. 그리고 예, Prolog에 데이터 (사실)를 저장할 수 있지만 SQL이 "수천 명의 동시 사용자가있는 수조 행의 저장, 검색, 프로젝션 및 감소"를 위해 설계된 것은 아닙니다.

또한 SQL은 주로 서버 언어 패러다임 인 반면 Prolog는 주로 클라이언트 언어 패러다임입니다.

---

맞습니다 : Prolog와 SQL은 이론적으로 관련이 있습니다 ( 이론적 차이점 에 대해 구체적으로 질문했습니다 ).

RBarryYoung의 답변 을 보완 하여 연결을 이해하는 데 도움이되는 몇 가지 힌트를 제공하여 기술을 연구하고 이해할 수있는 출발점을 확보하고 싶습니다.

Prolog와 SQL은 핵심을 공유합니다. Prolog의 하위 집합에서 표현할 수있는 모든 쿼리는 SQL의 하위 집합으로 표현 될 수 있으며 그 반대도 마찬가지입니다 . 즉, 이러한 하위 집합은 논리적으로 동일합니다.

이것이 사실 일 수있는 방법을 이해하려면 Prolog와 SQL 모두의 이론적 토대가 무엇인지 조사해야합니다.

• SQL ¹ 은 관계형 대수 ( RA )와 튜플 관계형 미적분 ( TRC ) ² 및 논리와 관련이없는 기타 부분 (예 : SUM, AVG 연산자, ORDER BY 등 ) 에서 모두 잘 통합되지 않은 여러 부분의 혼합입니다. 의 위에).
• RA 는 표현력이 안전한 (도메인 독립적) TRC와 동일합니다 (이를 Codd의 정리라고 함 ).
• RA 는 재귀 및 부정 (계층화)이없는 안전한 데이터 로그 에 대한 표현력과 동일 합니다 .
• 데이터 로그 는 Prolog ³ 의 "느슨한 부분 집합" 으로 간주 될 수 있습니다 . Prolog의 작동 의미 체계와 관련된 복잡성이 있다는 의미에서 "느슨한 하위 집합": " .. 절의 순서는 쿼리 호출의 결과를 계산하기위한 절의 순서에 의존하는 Prolog와 달리 Datalog에서 관련이 없습니다. " ( 여기에서 인용 ).

물론 이러한 하위 집합 중에는 더 많은 번역 작업이 필요합니다.

그럼에도 불구하고 Prolog-to-SQL 번역을 고려할 때 두 하위 집합의 표현력이 동등하다는 주장은 Turing 동등성 ^4에 대한 호소 이상 이라고 생각합니다.

메모:

1) 불행히도 SQL은 RDBMS 이론적 기초 ( 관계형 대수-계산 ) 와는 대조적으로 사용될 수 있습니다 . 예를 들어, SQL 테이블은 RA에 따라 반드시 관계가 아닙니다. 즉, (기본) 키가 없을 수 있으므로 중복 행이 허용됩니다. 이러한 테이블은 세트가 아니라 튜플의 다중 세트 (일명 백) 입니다. 이러한 맥락에서 관계가 설정된 RA에 대한 모든 이론적 결과가 반드시 유효한 것은 아닙니다.

2) SQL에서 TRC 로의 번역에 대해서는 A note on the translation of SQL to tuple calculus , also here (postscript paper)를 참조하십시오 .

3) Datalog와 Prolog의 차이점에 대한 자세한 내용은 Datalog 에 대해 항상 알고 싶었던 것 (그리고 결코 묻지 않음) 을 참조하십시오 (pdf 문서 -H . Datalog 및 Prolog 제목으로 직접 연결되는 6 페이지 링크 ).

4) 기록을 위해 : RA (및 이에 상응하는 안전한 TRC 및 재귀없는 안전한 Datalog)는 쿼리를 종료하지 않기 위해 의도적으로 튜링이 완전하지 않습니다.

역사적 노트 : Prolog와 Codd의 관계형 대수는 서로 다른 맥락에서 거의 같은시기 (60 년대 말 70 년대 초)에 고안되었습니다. Colmerauer는 자연어 처리를위한 Prolog를, Codd는 RA를 관계형 DBMS의 이론적 기반으로 생각했습니다. 따라서 Prolog-Datalog-RA-SQL 간의 모든 이론적 연결은 반드시 사후로 설정되었으며 모두 1 차 술어 미적분 (일명 1 차 논리 )을 기반으로한다는 사실을 암시합니다 .

---

Prolog와 SQL은 모두 1 차 논리를 기반으로하지만 SQL 테이블은 단순한 이진 관계인 반면 Prolog 술어는 Horn 절입니다.

이것은 모호한 이론적 요점이 아닙니다. SQL 바이너리 관계는 다음과 같은 형식의 사실 진술입니다.

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

여기서 f 는 관계의 이름이고 A ... N 은 해당 변수입니다. 프롤로그 이진 관계는 다음과 같은 형식의 의미입니다.

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

A ... N은 그 자체로 Horn 절입니다. SQL 관계는 데이터를 설명하는 효율적인 방법입니다. 프롤로그 관계는 데이터 자체가 데이터로 저장된 데이터 간의 복잡한 관계를 설명합니다.

Prolog에서는 데이터와 작업 사이에 분리가 없음을 이해하는 것이 중요합니다. 프롤로그 사실, 규칙 및 쿼리는 모두 혼절이므로 데이터는 대부분의 대학 과정에서 번역에서 손실됩니다. 프롤로그는 C와 같지 않지만 함수 대신 변수와 규칙 대신 사실을 사용합니다. 반면에 SQL은 규칙이나 쿼리가없는 Prolog와 매우 유사합니다.

SQL 쿼리는 논리 술어이기도하지만 SQL 쿼리는 데이터베이스 자체에 저장되지 않습니다. 오히려 사실 데이터베이스에서 데이터 세트를 추출하는 데 사용됩니다. 쿼리를 SQL 데이터베이스에 테이블 행으로 저장할 수 있지만 해당 형식으로 실행할 수는 없습니다.

Prolog 쿼리는 다른 Prolog 술어와 비슷하기 때문에 다른 Prolog 술어처럼 데이터베이스에 저장됩니다. 쿼리는 다음 형식의 Horn 절입니다.

<-B, C, D ... N

따라서 전례가 있지만 선행이없는 의미이므로 항상 거짓입니다. 사실은 다음과 같은 형식의 선행이 있지만 전례가없는 Horn 절입니다.

A <-

그래서 항상 사실입니다. 프롤로그는 반박으로 쿼리를 증명합니다.이를 증명하는 사실 (또는 규칙)을 찾을 수 없으면 쿼리가 항상 거짓이기 때문에 목표가 참이라고 말합니다. 이 과정에서 일부 변수가 바인딩되어 SQL이 SELECT 쿼리를 사용하는 것처럼 결과 집합을 구성 할 수 있습니다.

최신 SQL DBMS에는 저장 프로 시저 및 흐름 제어 언어와 같은 기능이 있으므로 SQL을 추론에 사용할 수 있습니다 ( SQL에서 추론을 수행 하려는 것이 아님). Prolog는 Horn 절의 데이터베이스에 맞게 조정 된 추론 엔진과 함께 제공됩니다. 이는 이진 관계로 명시된 사실 데이터베이스에 대한 추론을 수행하는 효율적인 방법이기 때문입니다 (예쁘기 때문 만이 아니라 아니요).

Prolog의 동형 적 특성 (데이터는 작동이 데이터 임)은 데이터베이스가 프로그램이기 때문에 새로운 새 데이터가 데이터베이스에 추가되어야 함을 의미합니다. 따라서 새로운 사실이 데이터베이스에 추가 될 때마다 (일반적으로 assert / 1 사용) 전체 프로그램을 디 컴파일해야합니다. 이것은 거대한 PITA이며 Prolog는 대용량 데이터 세트를 저장하는 데 비효율적입니다.하지만 데이터 검색시 비효율적이어야 할 이유가 없으며 Prolog 시스템은 그 목적을 위해 SQL 시스템과 동일한 알고리즘을 사용합니다. 반면 SQL은 저장과 검색 모두에 적합합니다.

Finally, Prolog has a few features that SQL just doesn't have, namely its super-pattern-matching called unification, negation as failure and syntactic elements that facilitate list processing and grammar declaration (Definite Clause Grammar notation). Those are just a happy accident and were mostly added to the language because they were en vogue in the time it was first created (thanks to LISP). SQL got recursive queries relatively recently so Prolog can't boast that anymore.

And of course both languages are weak at I/O and maths, although at least you can do some arithmetic in Prolog without having to pull your hair out all the way.

So, really, Prolog and SQL are as much alike as C and Haskell. They're both based on the same root abstraction, first order logic (like C and Haskell are both based on algebra) but things get very different pretty quickly after that. Also, from the point of view of language design, SQL tends to be fractured, with many different language features (pedicates, queries, data manipulation language....). Prolog's design is extremely consistent, so that the whole language is really just predicates and a few punctuation marks.

For me, the most important difference is this: I don't like SQL but I have to work with it. I love Prolog, but I can't use it at work. Life is unfair :)

---

The main difference in my eyes is that SQL retrieves rows from tables - that is, from a finite set of instantiated objects corresponding to certaing filter conditions. On the other hand, Prolog gives you theoretically all the instantiable objects that satisfy the conditions. And while in Prolog you can also retrieve entities from a finite set, in SQL you can't fetch all the values from a theoretically infinite set.

---

There are many differences which I think become clear when you start using them. Remember because of changes in terminology, somethings which are called the same thing in the past mean very different things now.

Very broad overview of difference.

SQL statements work against a relational database and query (ask for) data from that database, changes to that data and the results are exactly expressed in the language, whereas in Prolog you define facts and a logic engine generates new facts based off of the existing facts. New data (facts) are created via evaluation.

They both use something called queries (but they work totally differently) and they both have data (but use it differently.)

The use cases for SQL and Prolog are also totally different. It would never make sense to store an address list in Prolog whereas that is exactly what SQL was designed to do.

Simply put SQL is used to access a data store and Prolog is an expression evaluator.

---

I think the main difference is that Prolog is a query language used for matching complicated patterns against a database of simple facts. SQL on the other hand is limited to relational databases.

---

Just a few thoughts:

1. SQL is a query language for (maybe arbitrary complex) accessing to (relational) data, it's not a programming language.
2. Even if treat SQL as programming language - it's not Turing complete. I can hardly imagine sql query returning sum of 1 to 100 (for example).
3. SQL is language for accessing/manipulating (DML) to data bases, where Prolog is a language for working with knowledge bases (& rule resolution engine, of cause). Virtually Prolog is no more then simply unification & backtracking.
4. This is not saying about the application domains of SQL & Prolog, which are of cause totally different - efficient (regular) data storage & AI/symbolic computations/parsing/expert systems/constraint solvers/.../much more.

---

xonix, you need more development experience to say whether something can be done in sql or not.

Below are at least 2 solutions for your fibo series. One using Stored Procedure and the other using CTE. Take your pick.

METHOD 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

METHOD 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

참고URL : https://stackoverflow.com/questions/2117651/comparing-sql-and-prolog