SQL捕获

据Immerman，与相关联的复杂类SQL查询是完全类的安全的查询在 $\mathsf{Q(FO(COUNT))}$ （一阶查询加计数操作者）：SQL捕获安全查询。（换句话说，所有SQL查询具有复杂 $\mathsf{Q(FO(COUNT))}$ ，并且在所有的问题 $\mathsf{Q(FO(COUNT))}$ 可以表示为一个SQL查询。）

基于此结果，从理论上讲，存在许多可以有效解决但在SQL中无法表达的有趣问题。因此，仍然有效的SQL扩展似乎很有趣。所以这是我的问题：

是否有SQL的扩展（在行业中实现和使用），它可以捕获 $\mathsf{P}$ （即可以表示所有多项式时间可计算查询，而不能表示其他查询）？

我想要一种满足所有三个条件的数据库查询语言。这是很容易定义的扩展，它会扩展SQL和将捕获 $\mathsf{P}$ 。但是我的问题是，从实践的角度来看，这种语言是否有意义，所以我希望在实践中使用这种语言。如果不是这种情况，并且没有这种语言，那么我想知道是否有某种原因使这种语言从实际角度变得无趣？例如，实践中出现的查询通常是否足够简单，以至于不需要这种语言？

— 卡韦
source

@JD，对不起，但是根据您的评论，我认为您不明白这个问题。这个问题是明确的。用语言捕获复杂性类是一种标准术语。（我对语言应该是查询语言的偏爱还没有得到很好的定义，但这只是一种偏爱，我告诉过你我可以选择一种语言，如果没有这种偏爱的话就不会了。）

— 卡夫

@ Shog9，我已经回复了。JD不理解这个问题，他甚至不知道捕获的含义，并且不知道捕获P的语言在定义上不可能是图灵完成的。他希望以喜欢的方式来陈述它，我已经用通常的描述性复杂性术语和查询语言的复杂性来陈述了它，甚至还向他解释过这些。这里不清楚什么？

— 卡夫

@ Shog9，动机来自描述性复杂性。我正在尝试查看是否存在一种扩展SQL的语言，该语言在行业中使用了捕获P的语言。正如Immermann的结果所示，原始SQL语言相当薄弱，从理论角度来看，许多高效的计算都无法在其中进行陈述。另一方面，我们希望保持语言的高效性（即

）。有这种语言吗？（我认为这些对于熟悉描述性复杂性的人可能很清楚）。

P

$\mathsf{P}$

— 卡夫

@ Shog9：我看不到为什么这个问题需要主持人干预并被关闭。我对描述性复杂性很满意，可以说这是一个真实的问题（尽管可能更适合于TCS-这是一个很难回答的问题）。

— 亚历克斯（Alex）10 Brink 2012年

当我注意到另一个问题也被关闭（也获得了一致的投票）时，我问了一个有关meta的问题：meta.cs.stackexchange.com/questions/97/…–

— Alex 10 Brink

Answers:

关于您的主要问题，我推荐马丁·格罗（Martin Grohe）进行的简短调查。

实践中所需的查询通常是否足够简单，以至于不需要更强大的语言？

考虑到添加到常见查询语言（传递闭包，算术运算符，计数等）的大量扩展，我认为这在大多数情况下都是有效的。这是从某些人的观点出发的，该人是作为相对简单的网站和其他应用程序的自由开发人员而做过一些工作的，因此我不确定SQL在更大的行业/更大的数据库中的真正用途。

在极少数情况下，可能需要一种功能更强大的语言，我猜是软件开发人员通过使用编写应用程序的语言而不是查询（例如C ++或Java）来处理它们。

— 亚诺玛
source

首先，SQL的表达能力没有看起来那么清晰。事实证明，SQL的聚合，分组和算术功能具有非常微妙的效果。先验地，似乎可行的是，通过使用这些功能对代数运算符进行某种编码，实际上可以表达SQL的可到达性。事实证明，SQL-92实际上不是这种情况，它是“本地”的。

列昂尼德·利布金（Leonid Libkin）。 SQL的表达能力，TCS 296（3），379–404。doi：10.1016 / S0304-3975（02）00736-3（预印本）

这意味着SQL-92捕获PTIME需要扩展，并且该扩展允许结果语言为“非本地”。

然而，允许有序的结构，并与现实有限的运算，证明了SQL-92无法用语言表达的可达性将意味着统一 $\text{TC}^0 \subsetneq \text{NLOGSPACE}$ ，因此很可能是相当困难的。（可以说，SQL-92中的数据类型始终存在自然的线性排序，因此可以假定基础结构是有序的。）

然后情况又发生了变化，因为SQL：1999（SQL3）包含了递归。因此，SQL：1999似乎至少与定点逻辑具有相同的表达能力（尽管我认为细节可能仍然很棘手，包括顺序问题）。我不知道新构造是否使逻辑比捕获PTIME所需的逻辑更具表达性，并且需要进行一些研究才能确定这一点。同时，在2003年，2006年，2008年和2011 年进行了进一步修订（作为ISO文件，只有草稿是免费提供的）。这些修订添加了许多新功能，包括允许XQuery作为SQL查询的“一部分”。我的猜测是，“ SQL”现在比捕获PTIME所需的表达更具表现力，但是这样做所需的编码可能需要大型的，而不自然的查询，而实际系统可能不支持这种查询。

因此，我认为有证据表明，没有可以精确捕获PTIME的SQL的工业扩展模糊地回答您的问题。简而言之，工业扩展功能非常强大，可能已经超过了PTIME。如果确实SQL：1999已经足够强大，足以捕获至少PTIME，那么也不清楚“ SQL”在您的问题中的真正含义，因为必须定义“ SQL”来表示比SQL更早的版本： 1999年。

最后，Grohe对寻找捕获PTIME的逻辑的调查（Janoma也提到）不仅表明捕获捕获PTIME是棘手的，除非我们有线性顺序作为语言的一部分，而且证明没有这种逻辑也可能暗示。 $\text{P} \ne \text{NP}$

马丁·格罗（Martin Grohe），《寻求捕捉PTIME的逻辑》，LICS 2008，267-271。doi：10.1109 / LICS.2008.11（预印本）

— 安德拉斯·萨拉蒙（AndrásSalamon）
source

感谢András，特别是提到SQL3支持“递归”，我必须检查一下并了解已知的知识。:)

— Kaveh 2013年

ps：我想您已经为读者提供了有关复杂性理论和捕获P的逻辑的讨论，但是让我补充一下作为澄清：我使用SQL的意思是Immerman在结果中使用了SQL，结果使用SQL的精确定义。我知道关系复杂类分离和捕捉P上的逻辑问题，但我不认为他们的答案影响到我的问题，

— 卡韦赫

在回答我的问题可以是正的（或负），他们将与所有可能的答案P对NP和顺序无关的逻辑的P.存在一致

— 卡韦赫

Kaveh，如果您像Immerman那样定义SQL，那么我认为答案是“可能不会”，因为现有的工业扩展似乎太弱或太强大。但是（AFAIK）我们对此没有严格的证据。可能扩展的一些子集可以精确地捕捉PTIME，但我不知道我会通过努力将其隔离...规格要拖网

— 安德拉斯·萨拉蒙

-1

你提的问题不够清晰，如果你想扩展捕获，只有，或者如果它捕获和可能的事情外。看起来您只对确切的类感兴趣，因为您想要安全的查询，否则，SQL的任何Turing-complete扩展都可以。 $P$ $P$ $P$ $P$ $P$

我们不知道，如果。如果，然后能够捕获的SQL扩展，只是应该能够计算如果布尔公式是在多项式时间内可满足或解决任何其他在多项式时间的问题。 $P = NP$ $P = NP$ $P$ $P$ $NPC$

但是，如果，则如果给定的布尔公式可满足，则您的SQL扩展语言将无法计算。 $P \ne NP$

因此，我们有一个问题：是否存在以这种语言编写的算法（或查询或其他方法），可以确定布尔公式是否可满足？我无法回答这个问题（这里可能没有人可以回答，因为如果，这就是回答）。这个问题使我相信，这种语言实际上不可能存在。 $P = NP$

尽管它可能并非出于实际目的而存在，但它确实存在并且是可构造和可实现的。您可以使用能够模拟图灵机直至给定单步数的东西来定义该语言。IE，能够解决P-complete问题。但是，如果构造这样的东西，除了“给出一元步数”的限制外，它几乎是图灵完备的，这在类似SQL的语言中将其限制为仅安全查询是一种非常奇怪的方法。如果这些步骤是某个表的记录，则可以执行此操作，但是对于实际目的而言，这仍然没有任何价值。

— 维克多·斯塔夫萨（Victor Stafusa）
source

当我们说捕获复杂性类时，我们的意思就是那个复杂性类。例如，我们说语言

捕获了复杂度等级

。

F O

$\mathsf{FO}$

A C^{0}

$\mathsf{AC^0}$

— 卡夫

N P

$\mathsf{NP}$

P

$\mathsf{P}$

P

$\mathsf{P}$

F O (L F P)

$\mathsf{FO(LFP)}$ $\mathsf{P}$