在您的RDBMS实践中易于处理的数据库查询的“最大”大小（复杂性）是多少？

Question

随着查询大小的增长，对数据库的查询很容易被您在实践中使用的RDBMS变得难以计算。所以，我想，为了在实践中使用DB（使用DB作为后端进行编程），您必须知道可接受查询的复杂性/大小的界限。

如果您编写需要向关系数据库发出复杂查询的程序，您使用的RDMS有效回答的查询的“最大”大小/复杂性是什么？ < / p>

对关系数据库系统提出的查询的常规大小是多少？它比最大界限低多少？

提出这个问题的动机是the following theoretical speculation： 似乎已知要查找查询 Q 的答案 在数据库 D 上，需要时间 | D | ^{| Q |} ，以及 一个人无法摆脱指数 | Q | 。 （寻找一个集团是最坏情况查询的一个例子。） 由于 D 在实践中可能非常大，我们想知道为什么数据库可以工作。

Answer 1

对于注释，我会在你的问题中指出一个问题：你假设你总是想要一个精确的查询答案。实际情况并非如此。在挖掘大量数据时，答案的近似值就足够了。

对于PostgreSQL，我不知道对连接数有任何硬编码限制，但是根据事务隔离级别，我希望在它到达之前很久就会用完锁。

根据我的经验，在RDBMS上抛出的查询最多只有一些连接，并且以可以使用索引的方式编写。如果没有，开发人员通常会做错事。

有争议的是，偶尔的报告查询往往会变慢。这些可能涉及更复杂的语句，有几十个连接和联合，而聚合则没有。但在这种情况下，一个genetic algorithm开始了。计划程序在到达collapse limits时会尊重连接顺序，从而可以在给出有关数据重新分区的预先知识的情况下以最佳方式编写查询。

我看起来PostgreSQL吞下了二十多个连接的查询而没有打嗝......但更典型的是，将这些查询拆分成更小，更小的块是可能的，也是更有效的。和/或预先汇总它需要的一些结果。

对于大型查询或数据集的行计数，运行explain并返回计划程序的估计行数通常就足够了：知道正好有9,992个匹配行没有什么意义。

Answer 2

在我看来，这是一个非常好的问题。在典型的场景中，人类查询似乎小而简单（例如，包含很少的周期，如果有的话），并且RDBMS非常有效。现在想象一种情况，您可以在用户可用的某个词汇表中表达您的查询，该词汇表必须由计算机翻译成关系数据库的词汇表（例如，在Web上）。这是典型的语义Web场景，已经设计了像OWL 2这样的语言。在这种情况下，您的原始查询可能很小，但是提交给RDBMS的结果查询可能会呈指数级增大。