繁体   English   中英

通过物化路径查询SQL中的邻接表

[英]Query an adjacency list in SQL via a materialized path

我使用邻接列表 model(例如IdParentId )在 Microsoft SQL Server (2019) 中存储了一个大型层次结构(超过 2,500 条记录)。 我正在寻找一种有效的方法来根据层次结构中的特定路径查找记录。 换句话说,给定一个路径(例如/Root/FolderA/SubfolderA ),我想检索与最终节点关联的Id (即本例中的SubfolderA )。

注意:节点名称不是全局唯一的。 也就是说,我们不能只查找SubfolderA并假设它映射到/Root/FolderA/SubfolderA 层次结构中可能有多个名为SubfolderA的节点。

设置

等级制度

/Root
  /FolderA
    /SubfolderA
    /SubfolderB
  /FolderB
    /SubfolderA
    /SubfolderB

结构

CREATE 
TABLE   [dbo].[Tree] (
        [Id]            INT             NOT NULL PRIMARY KEY, 
        [ParentId]      INT             NULL, 
        [Name]          VARCHAR(255)    NOT NULL, 
        CONSTRAINT      [FK_Hierarchy]  
        FOREIGN KEY     (ParentId) 
        REFERENCES      [Tree]([Id])
)

数据

INSERT INTO Tree VALUES (1,    NULL, 'Root');
INSERT INTO Tree VALUES (2,    1,    'FolderA');
INSERT INTO Tree VALUES (3,    2,    'SubfolderA');
INSERT INTO Tree VALUES (4,    2,    'SubfolderB');
INSERT INTO Tree VALUES (5,    1,    'FolderB');
INSERT INTO Tree VALUES (6,    5,    'SubfolderA');
INSERT INTO Tree VALUES (7,    5,    'SubfolderB');

天真的方法

有很多关于如何将邻接列表转换为物化路径的主题,包括:

看法

我们可以使用这些方法之一将整个邻接列表转换为使用 rCTE 的物化路径:

CREATE 
VIEW            [dbo].[MaterializedPaths]
WITH            SCHEMABINDING
AS 

WITH RCTE AS (

  SELECT        Id,
                ParentId,
                CAST('/' + Name AS VARCHAR(255)) AS Path
  FROM          [dbo].[Tree] root
  WHERE         root.Id = 1

  UNION ALL

  SELECT        this.Id,
                this.ParentId,
                CAST(parent.Path + '/' + this.Name AS VARCHAR(255)) AS Path
  FROM          [dbo].[Tree] AS this
  INNER JOIN    RCTE parent
    ON          this.ParentId = parent.Id
)
SELECT          Id,
                Path
FROM            RCTE as hierarchy

Output

这会产生以下 output:

Id    Path
1     /Root
2     /Root/FolderA
3     /Root/FolderA/SubfolderA
4     /Root/FolderA/SubfolderB
5     /Root/FolderB
6     /Root/FolderB/SubfolderA
7     /Root/FolderB/SubfolderB

询问

我们可以使用一个简单的WHERE子句过滤 output:

SELECT          Id
FROM            MaterializedPaths
WHERE           Path = '/Root/FolderA/SubfolderA'

问题

天真的方法效果很好。 问题是它在查询大型层次结构时效率低得令人难以置信,因此速度很慢,因为它需要在每次调用时动态重建整个物化路径集。 就我而言,这需要 8-9 秒。 显然,我可以将这些数据存储在一个表中,并在数据发生变化时通过触发器重新生成它。 但我宁愿找到一个更有效的查询并避免额外的复杂性。

构造此查询的有效方法是什么? 或者,冒着使它成为 XY 问题的风险,有没有办法限制 rCTE,使其只需要评估层次结构中的节点,而不是每次都重建整个层次结构?

有没有办法限制rCTE,让它只需要评估层次结构中的节点,而不是每次都重建整个层次结构?

限制 rCTE

有一些方法可以限制每个递归查询的 scope,以便它只评估层次结构中的相关节点。 一种相当有效的方法是简单地将 rCTE 限制为源路径(让我们称之为@Path )以其开头的记录:

INNER JOIN  RCTE recursive
  ON        this.ParentId = recursive.Id
  AND       @Path LIKE CAST(recursive.Path + '/' + this.Name AS VARCHAR(MAX)) + '%'

这会将查询限制为您路径中的每条记录:

Id    Path
1     /Root
2     /Root/FolderA
3     /Root/FolderA/SubfolderA

然后可以根据一个简单的WHERE子句轻松过滤到最终记录:

WHERE Path = @Path

将其打包为 function

我们可以将其与原始 rCTE 组合成 function。将它们放在一起,它可能看起来像:

CREATE
FUNCTION        [dbo].[GetIdFromPath]
(
    @Path       VARCHAR(MAX)
)
RETURNS         INT
AS

BEGIN

  DECLARE       @Id         INT = -1


  ;WITH RCTE AS (

    SELECT      Id,
                ParentId,
                CAST('/' + Name AS VARCHAR(MAX)) AS Path
    FROM        [dbo].[Tree] root
    WHERE       root.Id = 1

    UNION ALL

    SELECT      this.Id,
                this.ParentId,
                CAST(parent.Path + '/' + this.Name AS VARCHAR(MAX)) AS Path
    FROM        [dbo].[Tree] AS this
    INNER JOIN  RCTE parent
      ON        Tree.ParentId = parent.Id
      AND       @Path LIKE CAST(parent.Path + '/' + this.Name AS VARCHAR(MAX)) + '%'
  )
  SELECT        @Id = Id
  FROM          RCTE as hierarchy
  WHERE         Path = @Path

  RETURN        @Id

END

按路径查询

鉴于上面的 function,您现在可以通过简单地将完整路径传递给GetIdFromPath() function 来查询邻接列表:

SELECT          dbo.GetIdFromPath('/Root/FolderA/SubfolderA') AS Id

其中,给定原始帖子中的样本数据,将返回3

表现

我已经针对具有 2,500 个样本记录的大小相当的表测试了这种方法,并且它始终在不到一秒的时间内很好地执行,这是对朴素方法的显着改进。 显然,您需要根据您自己的数据库和性能要求对其进行评估,以确定其是否足够高效。

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM