imz*_*hev 0 database complexity-theory relational-database
随着查询大小的增长,对数据库的查询很容易在您实际使用的RDBMS中变得难以计算.因此,我想,为了在实践中使用DB(使用DB作为后端进行编程),您必须知道可接受查询的复杂性/大小的界限.
如果编写需要向关系数据库发出复杂查询的程序,那么预期您使用的RDMS有效回答的查询的"最大"大小/复杂性是什么？
对关系数据库系统提出的查询的常规大小是多少？它低于最大界限多少？
提出这个问题的动机是以下理论推测:似乎已知要 在数据库D上找到查询Q的答案,需要时间| D | | Q | ,一个人无法摆脱指数| Q | .(寻找一个集团是最坏情况查询的一个例子.)由于D在实践中可能非常大,我们想知道为什么数据库可以工作.
对于注释,我会在你的问题中指出一个问题:你假设你总是想要一个精确的查询答案.实际情况并非如此.在挖掘大量数据时,答案的近似值就足够了.
在PostgreSQL的情况下,我不知道对连接数的任何硬编码限制,但是根据事务隔离级别,我希望在达到之前很久就会用完锁.
根据我的经验,在RDBMS上抛出的查询最多只有一些连接,并且以可以使用索引的方式编写.如果没有,开发人员通常会做一些非常错误的事情.
有争议的是,偶尔的报告查询往往会变慢.这些可能涉及更复杂的语句,有几十个连接和联合,而聚合则没有.但在这种情况下,一种遗传算法就会出现.并且计划程序在达到崩溃限制时将遵守连接顺序,从而可以在给出关于数据重新分区的预先知识的情况下以最佳方式编写查询.
我看起来像PostgreSQL swallow查询二十几个连接没有打嗝......但更典型的是,将这些查询分成更小,一口大小的块是可能的,更有效的; 和/或预先汇总它需要的一些结果.
对于大型查询或数据集的行计数,运行explain和返回计划程序的估计行数通常就足够了:知道正好有9,992个匹配行没有什么意义.
| 归档时间： |
|
| 查看次数： |
1691 次 |
| 最近记录： |