Comparing SQL and Prolog

2019-03-07 12:42发布

I've started learning Prolog and wondering about the theoretical difference from the SQL language.

For example:

  • both are declarative languages
  • both support a fact-driven knowledge database
  • both support question-styled data-retrieving
  • both support functional dependencies

Any more common points? Any notable differences?

标签: sql prolog
8条回答
看我几分像从前
2楼-- · 2019-03-07 13:17

Most of the (earlier) answers here are a reflection of the fact that most people do not know what SQL is (its an implementation of Relational Calculus) or what that means (that it's a form of Predicate Logic). The following statements are true of both Prolog and SQL:

  • they are both logic-driven
  • they can both store, express and use relations (logical relationships in Prolog)
  • they can both store and express complex logical conditions
  • they both have facts(data in SQL) and can derive conclusions from those facts
  • they both have queries, that do in fact mean the same thing
  • they both have data(facts in Prolog) and use them similarly
  • they are both programming languages
  • they are both turing-complete (though it is somewhat difficult to access this in both of them)
  • etc, etc..

Generally, people are not aware of these equivalences between them:

  1. "Facts" and "Data" are the same thing. This is straight out of Codd's original paper.
  2. A "Relation" in Relational Theory is the same thing as a "Table" in SQL, is the same thing as a Relation or relational function in Predicate Logic and is the same thing as a tuple-set in Set Theory
  3. An aliased table-expression (i.e., a View, etc.) in SQL is the same thing as a Rule in Prolog.

So what are their differences? Although they operate across the same conceptual domains, their focuses are in completely different directions. In Prolog terms, SQL is primarily a Fact and Relation(set) engine, whereas Prolog is primarily a Rules and Inferencing engine. Each can do the other, to a limited extent, but it becomes increasingly difficult with even small increases in complexity. For instance, you can do inferencing in SQL, but it is almost entirely manual in nature and not at all like the automatic forward-inferencing of Prolog. And yes, you can store data(facts) in Prolog, but it is not at all designed for the "storage, retrieval, projection and reduction of Trillions of rows with thousands of simultaneous users" that SQL is.

Plus, SQL is primarily a Server-language paradigm, whereas Prolog is primarily a Client-language paradigm.

查看更多
时光不老,我们不散
3楼-- · 2019-03-07 13:17

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.

查看更多
孤傲高冷的网名
4楼-- · 2019-03-07 13:18

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.

查看更多
聊天终结者
5楼-- · 2019-03-07 13:21

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
查看更多
不美不萌又怎样
6楼-- · 2019-03-07 13:25

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.
查看更多
聊天终结者
7楼-- · 2019-03-07 13:35

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.

查看更多
登录 后发表回答