Lesson Description
Learn how to connect related tables safely so your results stay accurate, readable, and business-ready.
Lesson 4 of 4
Progress: 0/3 exercises solved (0%)
Solve all exercises below to unlock the next lesson.
Lesson Description
Learn how to connect related tables safely so your results stay accurate, readable, and business-ready.
Easy Project
Mini project: Build a people-and-departments report that lists employee names, department names, and validates row counts to prove your join is correct.
JOIN Visual
employees
departments
Match keys first, then verify row counts after the join.
SQL allows chaining as many JOINs as needed. Each JOIN adds one table to the query.
Employee → Department → Location:
SELECT
e.first_name,
e.last_name,
d.name AS department,
l.city AS city
FROM employees e
JOIN departments d ON d.id = e.department_id
JOIN locations l ON l.id = d.location_id;
Customer → Order → Order Item → Product:
SELECT
c.first_name AS customer,
o.order_date,
p.name AS product,
oi.quantity,
oi.unit_price
FROM orders o
JOIN customers c ON c.id = o.customer_id
JOIN order_items oi ON oi.order_id = o.id
JOIN products p ON p.id = oi.product_id
ORDER BY o.order_date, c.last_name;
JOIN has its own ON clause.JOIN, LEFT JOIN, etc. in the same query.e, d, o, c, p).ON conditions vertically so the join structure is obvious at a glance.A junction table (like order_items) sits between two tables to represent a many-to-many relationship. Always join through it:
customers → orders → order_items → products
EXPLAIN ANALYZE shows the join strategy PostgreSQL chose and where time is spent.This lesson is part of Joins. Focus on the core idea in Joining three or more tables, then validate with deliberate practice.
What to master
Common mistakes
High-level strategy
Task ladder
Transparent data checks
Retention loop
Logical reasoning for commands
JOIN ... ON
Why: Connects rows only when keys truly match.
Memory cue: No key match = no trusted relationship.
LEFT JOIN
Why: Keeps base table rows even when lookup data is missing.
Memory cue: Left keeps the story intact.
COUNT(DISTINCT key)
Why: Confirms joins did not multiply business entities.
Memory cue: Distinct key count should stay believable.
Concept check
3 quick questions. One at a time. Instant score at the end.
From the HR sandbox, return first_name, last_name, department name (alias department), and job title (alias job_title) for every employee. Order by last_name.
From the store sandbox, join orders, customers, order_items, and products. Return customer first_name, product name, quantity, and unit_price. Order by orders.id, then products.name.
From the hospital sandbox, join appointments, patients, doctors, and departments. Return patient first_name, doctor first_name, department name (alias department), and appointment_date. Order by appointment_date, then patients.last_name.
Final checkpoint
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/3 solved (0%)
Finish this lesson to unlock next.