比较SQL和Prolog

Question

我开始学习Prolog并且想知道SQL语言的理论差异。

例如：

• 两者都是声明性语言
• 都支持事实驱动的知识库
• 都支持问题式数据检索
• 都支持功能依赖

还有更多共同点吗？有任何明显的差异吗？

Answer 1

这里的大多数（早期）答案反映了这样一个事实，即大多数人不知道SQL是什么（它是关系演算的实现）或者意味着什么（它是谓词逻辑的一种形式）。以下陈述适用于Prolog和SQL：

• 他们都是逻辑驱动的
• 他们可以存储，表达和使用关系（Prolog中的逻辑关系）
• 他们可以存储和表达复杂的逻辑条件
• 他们都有事实（SQL中的数据），可以从这些事实中得出结论
• 他们都有查询，这实际上意味着同样的事情
• 他们都有数据（Prolog中的事实）并且类似地使用它们
• 它们都是编程语言
• 他们都是图灵完成的（尽管在这两者中都很难获得）
• 等等。

一般来说，人们并不知道它们之间存在这些等价关系：

1. “事实”和“数据”是一回事。这完全出自Codd的原始论文。
2. 关系理论中的“关系”与SQL中的“表”相同，与谓词逻辑中的关系或关系函数相同，与集合论中的元组集相同
3. SQL中的别名表格表达式（即视图等）与Prolog中的规则相同。

那么他们的区别是什么？虽然它们在相同的概念领域中运作，但它们的重点在于完全不同的方向。在Prolog术语中，SQL主要是事实和关系（集）引擎，而Prolog主要是规则和推理引擎。每个人都可以在有限的范围内完成另一个，但即使复杂性增加很少，也变得越来越困难。例如，您可以在SQL中进行推理，但它几乎完全是手动的，而不像Prolog的自动前向推理。是的，您可以在Prolog中存储数据（事实），但它根本不是为SQL“存储，检索，预测和减少数千个并发用户的行数”而设计的。

另外，SQL主要是服务器语言范例，而Prolog主要是客户端语言范例。

Answer 2

你是对的：Prolog和SQL在理论上是相关的（你特别询问理论差异）。

我想补充RBarryYoung's answer，为您提供一些理解连接的提示，以便您有一个学习和理解技术性的起点。

Prolog和SQL共享一个核心：Prolog子集中可表达的每个查询都可以用SQL和反之的子集表示，即这些子集在逻辑上是等价的。

要了解这是如何成真的，您需要检查Prolog和SQL所基于的理论基础：

• SQL ¹ 是不同部分的混合，并不总是很好地集成，apparently from both关系代数（ RA ）和元组关系演算（ TRC ） ² 和其他与逻辑无关的部分（即SUM，AVG运算符，ORDER） BY等等。
• RA 相当于safe (domain-independent) TRC的表现力（这被称为Codd's theorem）。
• RA 相当于safe Datalog without recursion and with (stratified) negation的表现力。
• 数据记录可以被视为"loose subset" of Prolog ³ ;从某种意义上来说，这是一个“松散的子集”w.r.t. Prolog的操作语义：“ ..子句的排序与数据记录无关，与Prolog相反，后者依赖于计算查询调用结果的子句的顺序”（citing from here ）。

当然，这些子集中的某些内容需要更多的翻译工作。

尽管如此，我认为在考虑Prolog-to-时，两个子集的表达能力等效性的主张不仅仅是对Turing equivalence ⁴ 的吸引力。 SQL翻译。

备注：

1）不幸的是，SQL可以与RDBMS理论基础（关系代数 - 计算）形成对比;例如，SQL tables are not necessarily relations - 根据RA - 即它们可以没有（主）密钥，因此允许重复的行。这些表不是集合，而是multisets (aka bags)元组。在这种情况下，关系是集合的RA的所有理论结果都不一定有效。

2）有关从SQL到TRC的翻译，请参阅A note on the translation of SQL to tuple calculus，同时here (postscript paper)。

3）有关Datalog和Prolog之间差异的更多信息，请参阅What You Always Wanted to Know About Datalog (And Never Dared to Ask)（pdf文件 - 直接链接到第6页，标题为 H.Datalog和Prolog ）。

4）对于记录： RA （因此它们的等效安全TRC和安全数据记录没有递归）不是故意图灵完成，以避免永无止境查询。

历史记录： Prolog和Codd的关系代数是在同一时间（70年代末70年代末期）在不同背景下构思出来的--Colmerauer设想Prolog用于自然语言处理，而Codd将RA视为一个关系型DBMS的理论基础。因此，Prolog-Datalog-RA-SQL之间的任何理论联系都必须建立 a posteriori ，并隐含在它们都基于一阶谓词演算的事实中（又名first order logic）。

Answer 3

Prolog和SQL都基于一阶逻辑，但SQL表是简单的二元关系，而Prolog谓词是Horn子句。

这不是一个模糊的理论观点。 SQL二进制关系是事实的陈述，形式为：

f（A，B，C ... N）

其中 f 是关系的名称， A ... N 是其变量。 Prolog二元关系是形式的含义：

A＆lt; -B，C，D ... N

其中A ... N本身就是Horn条款。 SQL关系是描述数据的有效方式。 Prolog关系描述数据之间的复杂关系，它们本身存储为数据。

重要的是要理解在Prolog中，数据和操作之间没有分离。 Prolog事实，规则和查询都是Horn条款，因此数据是大多数大学课程中翻译丢失的内容。 Prolog不像C，但用事实代替变量和规则而不是函数。另一方面，SQL很像没有规则或查询的Prolog。

SQL查询也是逻辑谓词，但SQL查询不存储在数据库本身中。相反，它们用于从事实数据库中提取数据集。您可以将查询存储为SQL数据库中的表行，但无法以该形式执行。

Prolog查询与任何其他Prolog谓词一样存储在数据库中，因为它们与任何其他Prolog谓词一样。查询是以下形式的Horn子句：

＆lt; - B，C，D ... N

因此先例而不是先行的含义因此总是错误的。事实是Horn条款，具有先行但没有先例，形式如下：

A＆lt; -

总是如此。 Prolog通过反驳来证明一个查询：如果它找不到证明它的事实（或规则），它将说明目标是真的，因为查询总是错误的。在这个过程中，一些变量被绑定，因此可以构造结果集，就像SQL对SELECT查询一样。

现代SQL DBMS具有存储过程和流控制语言等功能，因此SQL可用于推理（而不是您希望在SQL中进行推理）。 Prolog准备好了一个调整到其Horn子句数据库的推理引擎，因为这是一种有效的方法，可以推断出作为二元关系的事实数据库（不，不仅仅因为它很漂亮）。

Prolog的homoiconic性质（数据是操作是数据）意味着必须将新的新数据添加到数据库中，因此要添加到程序中，因为数据库是程序。因此，每次向其数据库添加新事实（通常使用assert / 1）时，必须对整个程序进行反编译。这是一个巨大的PITA并且使Prolog在存储大型数据集方面效率低下，尽管没有理由为什么它必须在数据检索上效率低下，而Prolog系统将使用与SQL系统相同的算法来实现该目的。另一方面，SQL非常适合存储和检索。

最后，Prolog有一些SQL没有的功能，即它的超级模式匹配称为统一，否定为失败，以及便于列表处理和语法声明的句法元素（Definite Clause Grammar表示法）。这些只是一个快乐的事故，并且大部分被添加到语言中，因为它们在首次创建时很流行（感谢LISP）。 SQL最近得到了递归查询，因此Prolog不再夸耀它了。

当然，这两种语言在I / O和数学方面都很弱，但至少你可以在Prolog中做一些算法，而不必像以前一样所有。

所以，实际上，Prolog和SQL与C和Haskell一样多。它们都基于相同的根抽象，一阶逻辑（如C和Haskell都基于代数）但事后很快就会变得非常不同。此外，从语言设计的角度来看，SQL往往会断裂，具有许多不同的语言特征（pedicates，query，data manipulation language ......）。 Prolog的设计非常一致，因此整个语言实际上只是谓词和一些标点符号。

对我而言，最重要的区别是：我不喜欢SQL，但我必须使用它。我喜欢Prolog，但我不能在工作中使用它。生活是不公平的:)）

Answer 4

我眼中的主要区别在于SQL从表中检索行 - 即从与修改过滤条件对应的有限实例化对象集中检索行。另一方面，Prolog理论上为您提供满足条件的所有可实例化对象。而在Prolog中，您也可以从有限集中检索实体，在SQL中，您无法从理论上无限集中获取所有值。

Answer 5

当你开始使用它们时，我认为有许多不同之处。请记住，由于术语的变化，过去称为同一事物的事物现在意味着非常不同的事情。

非常广泛的差异概述。

SQL语句针对关系数据库和查询（请求）来自该数据库的数据，对该数据的更改以及结果在语言中准确表达，而在Prolog中，您定义事实并且逻辑引擎基于关闭生成新事实现有的事实。通过评估创建新数据（事实）。

他们都使用称为查询的东西（但它们的工作方式完全不同）并且它们都有数据（但使用的方式不同。）

SQL和Prolog的用例也完全不同。在Prolog中存储地址列表永远不会有意义，而这正是SQL的目的。

简单地说，SQL用于访问数据存储，而Prolog是表达式评估程序。

Answer 6

我认为主要区别在于Prolog是一种查询语言，用于将复杂模式与简单事实数据库进行匹配。另一方面，SQL仅限于关系数据库。

Answer 7

只是一些想法：

1. SQL是（可能是任意复杂的）访问（关系）数据的查询语言，它不是编程语言。
2. 即使将SQL视为编程语言 - 它也不是图灵完整的。我很难想象sql查询返回1到100之和（例如）。
3. SQL是用于访问/操作（DML）到数据基础的语言，其中Prolog是用于处理知识基础的语言（＆amp;规则解析引擎，原因）。事实上，Prolog不仅仅是统一＆amp;的回溯即可。
4. 这并不是说SQL＆amp;的应用领域。 Prolog，其原因完全不同 - 高效（常规）数据存储＆amp; AI /符号计算/解析/专家系统/约束求解器/.../更多。

Answer 8

xonix，你需要更多的开发经验来说明是否可以在sql中完成某些事情。

以下是至少2种fibo系列解决方案。一个使用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