Das Problem bei Ihrem Versuch ist die Filterung am Anfang. Wenn ich Recht habe, möchten Sie Ihre Daten nach ihren Beziehungen gruppieren (alle zusammen gruppieren), entweder aufsteigend oder absteigend oder eine Mischung aus ihnen. Zum Beispiel ID 100 hat Kind 101 , die ein weiteres untergeordnetes Element 102 hat , aber 102 hat einen übergeordneten 103 und Sie möchten, dass das Ergebnis diese vier sind (100, 101, 102, 103 ) für jede Eingabe, die sich in diesem Satz befindet. Aus diesem Grund können Sie am Anfang nicht filtern, da Sie nicht wissen können, welche Beziehung mit einer anderen Beziehung verkettet wird.
Das zu lösen ist nicht so einfach, wie es scheint, und Sie werden es nicht mit nur einer Rekursion lösen können.
Das Folgende ist eine Lösung, die ich vor langer Zeit gemacht habe, um all diese Beziehungen zusammenzufassen. Beachten Sie, dass die Berechnung bei großen Datensätzen (über 100.000) eine Weile dauern kann, da zuerst alle Gruppen identifiziert und das Ergebnis am Ende ausgewählt werden müssen.
CREATE PROCEDURE GetAncestors(@thingID INT)
AS
BEGIN
SET NOCOUNT ON
-- Load your data
IF OBJECT_ID('tempdb..#TreeRelationship') IS NOT NULL
DROP TABLE #TreeRelationship
CREATE TABLE #TreeRelationship (
RelationID INT IDENTITY(1,1) PRIMARY KEY NONCLUSTERED,
Parent INT,
Child INT,
GroupID INT)
INSERT INTO #TreeRelationship (
Parent,
Child)
SELECT
Parent = D.Parent,
Child = D.Child
FROM
Example AS D
UNION -- Data has to be loaded in both ways (direct and reverse) for algorithm to work correctly
SELECT
Parent = D.Child,
Child = D.Parent
FROM
Example AS D
-- Start algorithm
IF OBJECT_ID('tempdb..#FirstWork') IS NOT NULL
DROP TABLE #FirstWork
CREATE TABLE #FirstWork (
Parent INT,
Child INT,
ComponentID INT)
CREATE CLUSTERED INDEX CI_FirstWork ON #FirstWork (Parent, Child)
INSERT INTO #FirstWork (
Parent,
Child,
ComponentID)
SELECT DISTINCT
Parent = T.Parent,
Child = T.Child,
ComponentID = ROW_NUMBER() OVER (ORDER BY T.Parent, T.Child)
FROM
#TreeRelationship AS T
IF OBJECT_ID('tempdb..#SecondWork') IS NOT NULL
DROP TABLE #SecondWork
CREATE TABLE #SecondWork (
Component1 INT,
Component2 INT)
CREATE CLUSTERED INDEX CI_SecondWork ON #SecondWork (Component1)
DECLARE @v_CurrentDepthLevel INT = 0
WHILE @v_CurrentDepthLevel < 100 -- Relationships depth level can be controlled with this value
BEGIN
SET @v_CurrentDepthLevel = @v_CurrentDepthLevel + 1
TRUNCATE TABLE #SecondWork
INSERT INTO #SecondWork (
Component1,
Component2)
SELECT DISTINCT
Component1 = t1.ComponentID,
Component2 = t2.ComponentID
FROM
#FirstWork t1
INNER JOIN #FirstWork t2 on
t1.child = t2.parent OR
t1.parent = t2.parent
WHERE
t1.ComponentID <> t2.ComponentID
IF (SELECT COUNT(*) FROM #SecondWork) = 0
BREAK
UPDATE #FirstWork SET
ComponentID = CASE WHEN items.ComponentID < target THEN items.ComponentID ELSE target END
FROM
#FirstWork items
INNER JOIN (
SELECT
Source = Component1,
Target = MIN(Component2)
FROM
#SecondWork
GROUP BY
Component1
) new_components on new_components.source = ComponentID
UPDATE #FirstWork SET
ComponentID = target
FROM #FirstWork items
INNER JOIN(
SELECT
source = component1,
target = MIN(component2)
FROM
#SecondWork
GROUP BY
component1
) new_components ON new_components.source = ComponentID
END
;WITH Groupings AS
(
SELECT
parent,
child,
group_id = DENSE_RANK() OVER (ORDER BY ComponentID DESC)
FROM
#FirstWork
)
UPDATE FG SET
GroupID = IT.group_id
FROM
#TreeRelationship FG
INNER JOIN Groupings IT ON
IT.parent = FG.parent AND
IT.child = FG.child
-- Select the proper result
;WITH IdentifiedGroup AS
(
SELECT TOP 1
T.GroupID
FROM
#TreeRelationship AS T
WHERE
T.Parent = @thingID
)
SELECT DISTINCT
Result = T.Parent
FROM
#TreeRelationship AS T
INNER JOIN IdentifiedGroup AS I ON T.GroupID = I.GroupID
END
Sie werden das für @thingID sehen mit dem Wert 100 , 101 , 102 und 103 das Ergebnis sind diese vier und für Werte 200 , 201 und 202 die Ergebnisse sind diese drei.
Ich bin mir ziemlich sicher, dass dies keine optimale Lösung ist, aber es gibt die richtige Ausgabe und ich musste es nie optimieren, da es für meine Anforderungen schnell funktioniert.
