SQL Server : querying hierarchical and referenced data

Question

我正在开发一个具有层次结构的 Assets 数据库。此外，还有一个“ReferenceAsset”表，它有效地指向 Assets 。引用资源基本上起到覆盖的作用，但它被选择时就好像它是一个独特的新资源一样。设置的覆盖之一是parent_id。

与选择层次结构相关的列:
Assets :id(主要)、parent_id
Assets 引用:id(主要)、asset_id(外键-> Assets )、parent_id(始终是 Assets )
---已编辑 5/27----

相关表数据示例(连接后):

   id  | asset_id | name         |  parent_id  | milestone | type

    3       3       suit               null        march      shape
    4       4       suit_banker         3          april      texture
    5       5       tie                null        march      shape
    6       6       tie_red             5          march      texture
    7       7       tie_diamond         5          june       texture
   -5       6       tie_red             4          march      texture

id < 0(如最后一行)表示被引用的 Assets 。引用的资源有一些被覆盖的列(在本例中，只有parent_id 很重要)。

期望的是，如果我选择四月份的所有 Assets ，我应该进行二次选择以获取匹配查询的整个 Twig :

因此最初查询匹配将导致:

    4       4       suit_banker         3          april      texture

然后在 CTE 之后，我们得到完整的层次结构，我们的结果应该是这样的(到目前为止这是有效的)

    3       3       suit               null        march      shape
    4       4       suit_banker         3          april      texture
   -5       6       tie_red             4          march      texture

你看， id:-5 的父级就在那里，但是缺少的，也就是需要的，是引用的资源，以及引用的资源的父级:

    5       5       tie                null        march      shape
    6       6       tie_red             5          march      texture

目前我的解决方案适用于此，但它仅限于单一引用深度(而且我觉得实现非常丑陋)。

---已编辑----这是我的主要选择函数。这应该能更好地展示真正的复杂性所在:AssetReference。

Select A.id  as id, A.id as asset_id, A.name,A.parent_id as parent_id, A.subPath, T.name as typeName, A2.name as parent_name,  B.name as batchName, 
L.name as locationName,AO.owner_name as ownerName, T.id as typeID,
M.name as milestoneName, A.deleted as bDeleted, 0 as reference, W.phase_name, W.status_name
FROM Asset as A Inner Join Type as T on A.type_id = T.id
Inner Join Batch as B on A.batch_id = B.id
Left Join Location L on A.location_id = L.id
Left Join Asset A2 on A.parent_id = A2.id   
Left Join AssetOwner AO on A.owner_id = AO.owner_id
Left Join Milestone M on A.milestone_id = M.milestone_id
Left Join Workflow as W on W.asset_id = A.id
where A.deleted <= @showDeleted

UNION 

Select -1*AR.id as id, AR.asset_id as asset_id, A.name, AR.parent_id as parent_id, A.subPath, T.name as typeName, A2.name as parent_name,  B.name as batchName, 
L.name as locationName,AO.owner_name as ownerName, T.id as typeID,
M.name as milestoneName, A.deleted as bDeleted, 1 as reference, NULL as phase_name, NULL as status_name
FROM Asset as A Inner Join Type as T on A.type_id = T.id
Inner Join Batch as B on A.batch_id = B.id
Left Join Location L on A.location_id = L.id
Left Join Asset A2 on AR.parent_id = A2.id  
Left Join AssetOwner AO on A.owner_id = AO.owner_id
Left Join Milestone M on A.milestone_id = M.milestone_id
Inner Join AssetReference AR on AR.asset_id = A.id
where A.deleted <= @showDeleted

我有一个存储过程，它采用临时表 (#temp) 并查找层次结构的所有元素。我采用的策略是这样的:

1. 将整个系统层次结构选择到临时表 (#treeIDs) 中，该表由每个整个 Twig 的逗号分隔列表表示
2. 获取 Assets 匹配查询的完整层次结构(来自#temp)
3. 从层次结构中获取 Assets 指向的所有引用 Assets
4. 解析所有引用资源的层次结构

这目前有效，因为引用 Assets 始终是分支上的最后一项，但如果不是，我想我会遇到麻烦。我觉得我需要一些更好的递归形式。

这是我当前的代码，它正在工作，但我并不为此感到自豪，而且我知道它并不健壮(因为它仅在引用位于底部时才有效):

第 1 步:构建整个层次结构

;WITH Recursive_CTE AS (
 SELECT Cast(id as varchar(100)) as Hierarchy, parent_id, id
 FROM #assetIDs
Where parent_id is Null

UNION ALL

 SELECT
 CAST(parent.Hierarchy + ',' + CAST(t.id as varchar(100)) as varchar(100)) as Hierarchy, t.parent_id, t.id
 FROM Recursive_CTE parent
 INNER JOIN #assetIDs t ON t.parent_id = parent.id
)



Select Distinct h.id, Hierarchy as idList into #treeIDs
FROM ( Select Hierarchy, id FROM Recursive_CTE ) parent 
CROSS APPLY dbo.SplitIDs(Hierarchy) as h

第 2 步:选择与查询匹配的所有 Assets 的分支

Select DISTINCT L.id into #RelativeIDs FROM #treeIDs
CROSS APPLY dbo.SplitIDs(idList) as L
WHERE #treeIDs.id in (Select id FROM #temp)

第3步.获取分支中的所有引用 Assets (引用 Assets 具有负 id 值，因此 id < 0 部分)

Select asset_id  INTO #REFLinks FROM #AllAssets WHERE id in 
(Select #AllAssets.asset_id FROM #AllAssets Inner Join #RelativeIDs
 on #AllAssets.id = #RelativeIDs.id  Where #RelativeIDs.id < 0)

第 4 步:获取第 3 步中找到的任何内容的分支

Select DISTINCT L.id into #extraRelativeIDs FROM #treeIDs
CROSS APPLY dbo.SplitIDs(idList) as L
WHERE 
exists (Select #REFLinks.asset_id FROM #REFLinks WHERE #REFLinks.asset_id = #treeIDs.id) 
and Not Exists (select id FROM #RelativeIDs Where id = #treeIDs.id)

我试图只显示相关代码。我非常感谢任何可以帮助我找到更好解决方案的人!

Answer 1

--getting all of the children of a root node  ( could be > 1 ) and it would require revising the query a bit

DECLARE @AssetID int = (select AssetId from Asset where AssetID is null);


--algorithm is relational recursion
--gets the top level in hierarchy we want. The hierarchy column
--will show the row's place in the hierarchy from this query only
--not in the overall reality of the row's place in the table

WITH Hierarchy(Asset_ID, AssetID, Levelcode, Asset_hierarchy)
AS
(
 SELECT AssetID, Asset_ID,
        1 as levelcode, CAST(Assetid as varchar(max)) as Asset_hierarchy
 FROM   Asset 
 WHERE AssetID=@AssetID

 UNION ALL

 --joins back to the CTE to recursively retrieve the rows 
 --note that treelevel is incremented on each iteration

 SELECT  A.Parent_ID, B.AssetID,
        Levelcode + 1 as LevelCode,
        A.assetID + '\' + cast(A.Asset_id as varchar(20)) as Asset_Hierarchy
 FROM   Asset AS a
          INNER JOIN dbo.Batch AS Hierarchy
            --use to get children, since the parentId of the child will be set the value
            --of the current row
            on a.assetId= b.assetID 
--use to get parents, since the parent of the Asset_Hierarchy row will be the asset, 
            --not the parent.
            on Asset.AssetId= Asset_Hierarchy.parentID


SELECT  a.Assetid,a.name,
        Asset_Hierarchy.LevelCode, Asset_Hierarchy.hierarchy
FROM     Asset AS a
         INNER JOIN Asset_Hierarchy
              ON A.AssetID= Asset_Hierarchy.AssetID
ORDER BY    Hierarchy ;
--return results from the CTE, joining to the Asset data to get the asset name
---that is the structure you will want. I would need a little more clarification of your table structure