我正在尝试找出哪种方法更适合实现多个查询,如果事务中的每个下一个查询都取决于上一个查询的结果。
例如,有一些表
id | values
1 | 253
2 | 742
...| ...
并且查询堆栈中的第一个查询从具有给定id的行中返回字段values的值v1。查询堆栈中的第二个查询应该从前一个查询返回的id等于v1的行中返回字段values的值v2。我了解该任务可能看起来很奇怪,但这是需要解决的更复杂和有用的任务的简化版本。
对我来说,解决这个问题的第一种(最简单的方法是在一个事务中将多个请求相互依赖结合在一起。但是,我找不到与如何在单个事务中执行所描述的查询堆栈有关的任何信息。事务中的每个下一个查询都会等待上一个查询响应吗?每次将请求发送到数据库并等待来自它的响应是否要花费时间,或者所有请求将与一个事务同时发送到数据库并等待来自数据库的响应是否会发生一次?
我想理解-在DBMS端使用过程是否有优势?
我想使用过程可以减少从应用程序到数据库的查询数量。而且我想每一个这样的请求都是昂贵的。
我问这个问题的答案-为了提高性能并减少与数据库交互的时间,哪种方法更适合描述的任务?
谢谢!
UPD:
我还尝试使用带有递归cte的查询来解决此任务。
[不幸的是,在实际任务中,我必须在另一个递归查询的每次迭代中使用这样的递归查询。结果证明该算法非常复杂,我很难开发它。因此,问题是-也许在应用程序级别描述的一个事务中使用大量查询会带来相似的性能结果吗?但是我担心这种方法将导致等待数据库针对每个请求的响应,而且速度非常慢。
或者我可以组合使用这些方法-也就是说,使用递归cte读取部分数据,然后根据从先前递归cte接收到的数据等构成下一个递归cte,并在一个事务中全部执行。
您正在描述一个迭代过程,可以用递归查询在SQL中实现。
在Postgres中,它看起来像:
with recursive cte as (
-- anchor
select id, values, 0 lvl from mytable where id = ?
union all
-- recursion
select t.id, t.values, lvl = 1
from mytable t
inner join cte c on c.values = t.id
)
select * from cte
锚点通过id
选择起始行,然后递归部分遵循该关系,直到耗尽为止。您可能需要阅读Postgres documentation on this以获得更多详细信息和说明。
尽管可能比重复查询方法更有效,但是对于深度嵌套的层次结构,递归查询并不是很有效; SQL是一种基于语言的语言,并不是针对此类活动而设计的。