Lesson 4 of 4

Progress: 0/4 exercises solved (0%)

← PreviousFinal lesson

Solve all exercises below to unlock the next lesson.

EXISTS — test for related rows

Lesson Description

Build confidence in Filtering & Logic by practicing this lesson with structured prompts and real query execution.

Easy Project

Mini project: Turn this lesson into a real-world query artifact by writing one clean business report query and validating output quality.

EXISTS — test for the presence of related rows

EXISTS returns TRUE if its subquery returns at least one row. It stops as soon as the first match is found, which makes it efficient.

Syntax

SELECT col1, col2
FROM table_name t
WHERE EXISTS (
  SELECT 1
  FROM other_table ot
  WHERE ot.fk = t.id
);

The inner SELECT 1 is conventional — EXISTS only cares whether any row is returned, not what the columns contain.

Example: customers with at least one order

SELECT first_name, last_name
FROM customers c
WHERE EXISTS (
  SELECT 1 FROM orders o
  WHERE o.customer_id = c.id
);

NOT EXISTS — find unmatched rows

SELECT first_name, last_name
FROM customers c
WHERE NOT EXISTS (
  SELECT 1 FROM orders o
  WHERE o.customer_id = c.id
);

This returns customers who have never placed an order.

EXISTS vs IN vs LEFT JOIN

ApproachNotes
EXISTSShort-circuits at first match; safe with NULLs
IN (subquery)Simple; beware NOT IN with NULLs in list
LEFT JOIN ... WHERE rhs IS NULLSame as NOT EXISTS; sometimes faster

Critical rule: Prefer NOT EXISTS over NOT IN when the subquery could return NULLs — NOT IN silently returns zero rows if the list contains a NULL.

Tips

  • EXISTS is a semi-join — it does not pull data from the subquery, only checks for existence.
  • The correlated subquery (referencing the outer query) runs once per outer row. For large tables, a JOIN may be faster.

Learning context

This lesson is part of Filtering & Logic. Focus on the core idea in EXISTS — test for related rows, then validate with deliberate practice.

What to master

  • Understand clause order and intent
  • Write deterministic result queries
  • Use clear aliases and readable structure

Common mistakes

  • Skipping ORDER BY in final outputs
  • Using joins before validating base rows
  • Not checking row counts after changes

High-level strategy

  • Start simple, then layer complexity
  • Run often and compare expected shape
  • Refactor with CTEs when logic grows

Task ladder

  1. Baseline query: get a correct first output.
  2. Add one complication: edge case, join, filter, or ranking rule.
  3. Re-run and refine until output is stable and explainable.

Transparent data checks

  • Check row count before and after each major clause.
  • Validate one manual sample row for correctness.
  • Confirm final ordering and column naming for trust.

Retention loop

  • Run the solution once.
  • Rewrite from memory with one variation.
  • Explain the logic in plain English in one sentence.

Logical reasoning for commands

WHERE

Why: Limits rows to only the business-relevant subset.

Memory cue: Filter early to reduce noise.

ORDER BY

Why: Makes output deterministic and reviewable.

Memory cue: No ORDER BY means no guaranteed row order.

AS alias

Why: Makes output columns readable for teams and reports.

Memory cue: If the name is clear, the query is easier to trust.

Concept check

Quick check: EXISTS — test for related rows

3 quick questions. One at a time. Instant score at the end.

Exercise 1

Customers who have placed orders (EXISTS)

Commerce Operations Intelligenceeasy

From the store sandbox, return first_name and last_name of customers who have placed at least one order. Use EXISTS. Order by last_name.

Run a query to see results here.
Exercise 2

Customers with no orders (NOT EXISTS)

Commerce Operations Intelligenceeasy

From the store sandbox, return first_name and last_name of customers who have never placed an order. Use NOT EXISTS. Order by last_name.

Run a query to see results here.
Exercise 3

Patients who have had at least one appointment

Clinical Care Performanceeasy

From the hospital sandbox, return first_name and last_name of patients who appear in the appointments table at least once. Use EXISTS. Order by last_name.

Run a query to see results here.
Exercise 4

Employees who manage at least one other employee

Enterprise Workforce Analyticseasy

Return first_name and last_name of HR employees who are the manager_id for at least one other employee. Use EXISTS. Order by last_name.

Run a query to see results here.

Final checkpoint

End-of-course high-level quiz

Pass mark: 80%. Review each explanation after you submit.

1. Which clause should you use to filter grouped results?

2. What is the safest way to avoid accidental row multiplication in joins?

3. Which feature is best for ranking rows within partitions?

4. Why should final analytical queries usually include ORDER BY?

5. When query logic gets complex, what improves readability most?

Lesson 4 of 4

0/4 solved (0%)

← PreviousFinal lesson

Finish this lesson to unlock next.