Recursive CTE for hierarchical data in SQL - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to start the recursive CTE by selecting the root nodes (where parent_id is NULL).

SQL

WITH RECURSIVE subordinates AS (
  SELECT id, name, parent_id
  FROM employees
  WHERE parent_id IS [1]
)

Drag options to blanks, or click blank then click option'

ANULL

BNOT NULL

C0

D''

Attempts:

3 left

💡 Hint

Common Mistakes

Using '=' instead of 'IS' to check for NULL

Selecting rows where parent_id is 0 instead of NULL

The root nodes in a hierarchical table usually have parent_id as NULL. So the base case selects rows where parent_id IS NULL.

2fill in blank

medium

Complete the recursive part to join the CTE with the employees table to find subordinates.

SQL

WITH RECURSIVE subordinates AS (
  SELECT id, name, parent_id
  FROM employees
  WHERE parent_id IS NULL
  UNION ALL
  SELECT e.id, e.name, e.parent_id
  FROM employees e
  JOIN subordinates s ON e.[1] = s.id
)

Drag options to blanks, or click blank then click option'

Aname

Bid

Cparent_id

Dmanager_id

Attempts:

3 left

💡 Hint

Common Mistakes

Joining on employee id instead of parent_id

Using wrong column names like 'manager_id' if not defined

The recursive step joins employees where their parent_id matches the id of the current subordinates, thus finding direct reports.

3fill in blank

hard

Fix the error in the final SELECT statement to get all subordinates' names.

SQL

WITH RECURSIVE subordinates AS (
  SELECT id, name, parent_id
  FROM employees
  WHERE parent_id IS NULL
  UNION ALL
  SELECT e.id, e.name, e.parent_id
  FROM employees e
  JOIN subordinates s ON e.parent_id = s.id
)
SELECT [1] FROM subordinates;

Drag options to blanks, or click blank then click option'

Aname

Bid, parent_id

C*

Dparent_id

Attempts:

3 left

💡 Hint

Common Mistakes

Selecting only ids or parent_ids instead of names

Selecting * which is allowed but not focused on the question

The question asks for all subordinates' names, so selecting the name column is correct.

4fill in blank

hard

Fill both blanks to add a level column showing depth in the hierarchy and increment it in recursion.

SQL

WITH RECURSIVE subordinates AS (
  SELECT id, name, parent_id, 1 AS [1]
  FROM employees
  WHERE parent_id IS NULL
  UNION ALL
  SELECT e.id, e.name, e.parent_id, s.[2] + 1
  FROM employees e
  JOIN subordinates s ON e.parent_id = s.id
)
SELECT * FROM subordinates;

Drag options to blanks, or click blank then click option'

Alevel

Bdepth

Attempts:

3 left

💡 Hint

Common Mistakes

Using different names like 'level' and 'depth' inconsistently

Forgetting to increment the level in the recursive part

The column name must be consistent in both parts of the CTE. Here, level is used to track depth, so both blanks should be level.

5fill in blank

hard

Fill all three blanks to filter subordinates at level greater than 2 and order by level ascending.

SQL

WITH RECURSIVE subordinates AS (
  SELECT id, name, parent_id, 1 AS level
  FROM employees
  WHERE parent_id IS NULL
  UNION ALL
  SELECT e.id, e.name, e.parent_id, s.level + 1
  FROM employees e
  JOIN subordinates s ON e.parent_id = s.id
)
SELECT name, level FROM subordinates
WHERE level [1] 2
ORDER BY level [2];

-- Use [3] to specify ascending order

Drag options to blanks, or click blank then click option'

A>

B<

CASC

DDESC

Attempts:

3 left

💡 Hint

Common Mistakes

Using '<' instead of '>' to filter levels

Ordering by DESC when ascending is requested

To get subordinates deeper than level 2, use level > 2. To order ascending, use ORDER BY level ASC. The third blank clarifies the order direction as ASC.

Practice

1. What is the main purpose of a RECURSIVE CTE in SQL when working with hierarchical data?

easy

A. To speed up simple SELECT queries without joins

B. To repeatedly query connected rows to explore hierarchical relationships

C. To create temporary tables for storing unrelated data

D. To update multiple tables at once

Solution

1. Step 1: Understand the role of recursive CTEs

   Recursive CTEs allow querying hierarchical or connected data by repeatedly joining rows to find related entries.

2. Step 2: Compare options with this purpose

   Only To repeatedly query connected rows to explore hierarchical relationships describes this repeated querying of connected rows to explore hierarchies.

3. Final Answer:

   To repeatedly query connected rows to explore hierarchical relationships -> Option B

4. Quick Check:

   Recursive CTE = repeated connected row queries [OK]

Hint: Recursive CTEs repeatedly join related rows to explore hierarchies [OK]

Common Mistakes:

• Confusing recursive CTEs with simple temporary tables
• Thinking recursive CTEs speed up unrelated queries
• Assuming recursive CTEs update data

2. Which of the following is the correct syntax to start a recursive CTE named OrgChart in SQL?

easy

A. DECLARE RECURSIVE OrgChart BEGIN ... END

B. CREATE RECURSIVE TABLE OrgChart AS ( ... )

C. SELECT RECURSIVE OrgChart FROM ...

D. WITH RECURSIVE OrgChart AS ( ... )

Solution

1. Step 1: Recall recursive CTE syntax

   The correct way to start a recursive CTE is using WITH RECURSIVE Name AS ( ... ).

2. Step 2: Check each option

   WITH RECURSIVE OrgChart AS ( ... ) matches the correct syntax. Options A, B, and C use invalid or unrelated SQL commands.

3. Final Answer:

   WITH RECURSIVE OrgChart AS ( ... ) -> Option D

4. Quick Check:

   Recursive CTE starts with WITH RECURSIVE [OK]

Hint: Recursive CTE always starts with WITH RECURSIVE [OK]

Common Mistakes:

• Using CREATE instead of WITH for CTEs
• Trying to SELECT RECURSIVE directly
• Using DECLARE which is for procedural code

3. Given the table Employees(id, name, manager_id) where manager_id references id, what will the following query return?

WITH RECURSIVE Subordinates AS (
  SELECT id, name, manager_id FROM Employees WHERE id = 2
  UNION ALL
  SELECT e.id, e.name, e.manager_id FROM Employees e
  JOIN Subordinates s ON e.manager_id = s.id
)
SELECT * FROM Subordinates;

medium

A. All employees who report directly or indirectly to employee with id 2

B. Only the employee with id 2

C. All employees who have no manager

D. All employees in the company

Solution

1. Step 1: Analyze the base query

   The base query selects the employee with id = 2.

2. Step 2: Analyze the recursive part

   The recursive part joins employees whose manager_id matches any id found so far, thus finding all subordinates under employee 2.

3. Final Answer:

   All employees who report directly or indirectly to employee with id 2 -> Option A

4. Quick Check:

   Recursive join finds all subordinates [OK]

Hint: Recursive CTE with join on manager_id finds all subordinates [OK]

Common Mistakes:

• Thinking it returns only the base employee
• Assuming it returns employees without managers
• Believing it returns all employees regardless

4. Identify the error in this recursive CTE that tries to list all descendants of a node in a tree:

WITH RECURSIVE Descendants AS (
  SELECT id, parent_id FROM Tree WHERE id = 1
  UNION ALL
  SELECT t.id, t.parent_id FROM Tree t
  JOIN Descendants d ON t.id = d.parent_id
)
SELECT * FROM Descendants;

medium

A. The JOIN condition should be ON t.parent_id = d.id, not t.id = d.parent_id

B. The base query should select from Descendants, not Tree

C. Recursive CTEs cannot use JOINs

D. The recursive part should use UNION, not UNION ALL

Solution

1. Step 1: Understand the tree relationship

   Each node's parent_id points to its parent. To find descendants, join where child's parent_id equals parent's id.

2. Step 2: Check the JOIN condition

   The query incorrectly joins on t.id = d.parent_id. It should be t.parent_id = d.id to find children of current nodes.

3. Final Answer:

   The JOIN condition should be ON t.parent_id = d.id, not t.id = d.parent_id -> Option A

4. Quick Check:

   Join child parent_id to parent id [OK]

Hint: Join child's parent_id to parent's id to find descendants [OK]

Common Mistakes:

• Reversing join condition columns
• Using base query from recursive CTE itself
• Thinking recursive CTEs can't use JOIN
• Confusing UNION and UNION ALL usage

5. You have a parts list table Parts(id, name, parent_part_id) representing assemblies and subassemblies. Write a recursive CTE query to find the full hierarchy of parts under part with id = 10, including the root part itself, and show the level (depth) of each part in the hierarchy starting at 0 for the root. Which query is correct?

hard

A. WITH RECURSIVE PartHierarchy AS (
SELECT id, name, parent_part_id FROM Parts WHERE parent_part_id IS NULL
UNION ALL
SELECT p.id, p.name, p.parent_part_id FROM Parts p
JOIN PartHierarchy ph ON p.id = ph.parent_part_id
)
SELECT * FROM PartHierarchy WHERE id = 10;

B. WITH RECURSIVE PartHierarchy AS (
SELECT id, name, parent_part_id, 1 AS level FROM Parts WHERE id = 10
UNION ALL
SELECT p.id, p.name, p.parent_part_id, ph.level - 1 FROM Parts p
JOIN PartHierarchy ph ON p.id = ph.parent_part_id
)
SELECT * FROM PartHierarchy;

C. WITH RECURSIVE PartHierarchy AS (
SELECT id, name, parent_part_id, 0 AS level FROM Parts WHERE id = 10
UNION ALL
SELECT p.id, p.name, p.parent_part_id, ph.level + 1 FROM Parts p
JOIN PartHierarchy ph ON p.parent_part_id = ph.id
)
SELECT * FROM PartHierarchy;

D. WITH RECURSIVE PartHierarchy AS (
SELECT id, name, parent_part_id, 0 AS level FROM Parts WHERE id = 10
UNION ALL
SELECT p.id, p.name, p.parent_part_id, ph.level + 1 FROM Parts p
JOIN PartHierarchy ph ON p.id = ph.parent_part_id
)
SELECT * FROM PartHierarchy;

Solution

1. Step 1: Identify the base case and level

   The base query selects the root part with id=10 and sets level to 0.

2. Step 2: Check the recursive join and level increment

   The recursive part joins parts where parent_part_id matches current part's id, and increments level by 1 to track depth.

3. Step 3: Verify options

   WITH RECURSIVE PartHierarchy AS ( SELECT id, name, parent_part_id, 0 AS level FROM Parts WHERE id = 10 UNION ALL SELECT p.id, p.name, p.parent_part_id, ph.level + 1 FROM Parts p JOIN PartHierarchy ph ON p.parent_part_id = ph.id ) SELECT * FROM PartHierarchy; correctly implements this logic. WITH RECURSIVE PartHierarchy AS ( SELECT id, name, parent_part_id, 1 AS level FROM Parts WHERE id = 10 UNION ALL SELECT p.id, p.name, p.parent_part_id, ph.level - 1 FROM Parts p JOIN PartHierarchy ph ON p.id = ph.parent_part_id ) SELECT * FROM PartHierarchy; has wrong join direction and decrements level. WITH RECURSIVE PartHierarchy AS ( SELECT id, name, parent_part_id FROM Parts WHERE parent_part_id IS NULL UNION ALL SELECT p.id, p.name, p.parent_part_id FROM Parts p JOIN PartHierarchy ph ON p.id = ph.parent_part_id ) SELECT * FROM PartHierarchy WHERE id = 10; starts from root parts but filters later, missing the correct root. WITH RECURSIVE PartHierarchy AS ( SELECT id, name, parent_part_id, 0 AS level FROM Parts WHERE id = 10 UNION ALL SELECT p.id, p.name, p.parent_part_id, ph.level + 1 FROM Parts p JOIN PartHierarchy ph ON p.id = ph.parent_part_id ) SELECT * FROM PartHierarchy; has wrong join direction.

4. Final Answer:

   The query with base WHERE id=10, level 0, JOIN p.parent_part_id=ph.id, level+1 -> Option C

5. Quick Check:

   Join on child.parent_part_id = parent.id, level + 1 [OK]

Hint: Join child.parent_part_id = parent.id and increment level [OK]

Common Mistakes:

• Reversing join condition (parent to child)
• Starting level at 1 or decrementing level
• Filtering after recursion instead of base case
• Using wrong root selection