Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 373
  • Last Modified:

Recursive SQL


I Have a table like below

ProductID          RepProdID
######           ###########
a                         b
a                         c
a                         d
b                         a
b                         e
b                         f
b                         z
c                         a
c                         k

Means, The product a is replaced by b and etc

Now, If I query with product ID "a" then I want the output

B, C, D, E, F, Z, K.

Since product "a" is the source of all this products (please note that b to a is also possible which leads to infinite loop).

I want t-sql query to achieve this without infinite recursive loop.

How can I achieve this? Please help.
1 Solution
Using a view, substitute your view and table names for T and V

create view V as
select productid, repprodid from T
   where ProductID < RepProdID
      or not exists (select * from T as C where T.productID = c.Repprodid and c.productid = t.repprodid)
group by productid, repprodid

;with cte
select T.RepProdID from V as T where T.ProductID = 'f'
union all
select T.RepProdID from V as T
inner join cte on cte.RepProdID = T.ProductID
select * from cte  
Typically, infinite loops in a hierarchy means that data has errors, but here is another way to do it.  It actually looks for repeating patterns and then ignores them.



SET @Anchor = 'a'

;WITH RecursiveCTE
	SELECT ProductID, RepProdID, 1 AS [Level], 'N' AS Cycle,
		CAST('.' + CAST(ProductID AS VARCHAR(8)) + '.' AS VARCHAR(MAX)) AS CTEPath
	FROM YourTable
	WHERE ProductID = @Anchor
	SELECT a.ProductID, a.RepProdID, b.[Level] + 1 AS [Level],
			WHEN b.CTEPath LIKE '%.' + CAST(a.ProductID AS VARCHAR(8)) + '.%' THEN 'Y'
			ELSE 'N'
		CAST(b.CTEPath + CAST(a.ProductID AS VARCHAR(8)) + '.' AS VARCHAR(MAX))
		RecursiveCTE b ON a.ProductID = b.RepProdID AND b.Cycle = 'N'
	RepProdID <> @Anchor
OPTION(Maxrecursion 100)

Open in new window

radcaesarAuthor Commented:
Just a clarification

It will work for values like ML005J, 5XP00M right.

I have this doubt because of the below where condition check.

where ProductID < RepProdID

Please explain this.
>It will work for values like ML005J, 5XP00M right.

Well, I think so...< works fine for character values.

The goal is to eliminate the bi-directional parallelism (a replaces b, b replaces a) and infinite recursions (a replaces b, b replaces c, c replaces a).  

BTW, if "a replaces b" is equivalent to "b replaces a", then it may behoove you to add a check constraint for ProductID < RepProdID and eliminate the opposite, but equivalent relationships from your table. That makes clean retrival so much easier.  

If "a replaces b" is NOT equivalent to "b replaces a", then it's not clear what the difference might be.

 "a replaces b" is equivalent to "b replaces a"

Also, I think this view would also work and might be more self-documenting:

create view V as
select productid, repprodid from T where ProductID < RepProdID
select repprodid, productid from T where ProductID > RepProdID

Olaf DoschkeSoftware DeveloperCommented:
The major ingredient will surely be CTE, so if you're not familiar with common table expressions used for recursion, maybe have a read on http://www.simple-talk.com/sql/t-sql-programming/sql-server-cte-basics/

The main question really is, whether the hierarchical data pointing back to a root node really is valid. I think so, because of my interpretation of what replacement of a product means. I may be wrong on the details, but if you think about the development of a product in the normal case older products are  replaced by newer ones only, but there might be cases a new product turns out to be less good than it's predecessor, which I imagine could be the reason a replacement product can be replaced by it's predecessor.

In that case, I'd say you could also add A to the result, as A indirectly is/was it's own replacement product. That aside the easiest yet not most effective way is to use tha maxrecursion option to cut off infinite loops after a recursion level never reached in a normal case, which is the brute force method to avoid infinite recursions. I like both the idea of checking an anchor, but the infinite loop might not go back to the anchor. Only allowing ProductID < RepProdID would not put A into the result, which you also don't want, so that would also be ok, as that only looks for forward replacements, but then there might be a history of replacements as in a->f->b->z, which would miss b and z in that case, but surely it's avoiding recursion.

It might be easier to understand and maintain to not put the recursion into the query, but instead make a query determining only the direct replacement products and use that simpler query in a recursive function starting with a root product, collecting it's direct replacement products and in the next recursion level the replacement products for those products found etc., collecting the intermediate products into a central result list, unless a call yields no further products into that list. In each level of recursion you only need to let that recursive function call itself with products neww to the list, so recursion ends naturally.

Bye, Olaf.

Featured Post

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now