Skip to main content
Xenors Xenors
XENORS
Home › Data Science › SQL Joins: INNER, LEFT, RIGHT & FULL with Examples
Module lesson · 18 of 45

SQL Joins: INNER, LEFT, RIGHT & FULL with Examples

Understand INNER, LEFT, RIGHT and FULL OUTER JOIN with practical examples, row-count checks and duplicate-key warnings.

By Ashok Kumar YadavHands-on examples + practiceDataset + notebook included
SQL Joins: INNER, LEFT, RIGHT & FULL with Examples

Understand INNER, LEFT, RIGHT and FULL OUTER JOIN with practical examples, row-count checks and duplicate-key warnings. Work through the SQL Joins examples in order, then change one assumption and explain whether your interpretation still holds. This page targets the practical intent behind join behavior, not repetition of the phrase itself.

Editorial note: Publication metadata for SQL Joins is intentionally unset until this URL is actually released; the lesson already includes its own examples, CSV and notebook.

Start with the table grain before writing join behavior

A customer table joined to orders with LEFT JOIN keeps customers who never purchased. That matters when measuring conversion, while an INNER JOIN would silently remove them.

  • INNER JOIN keeps matched keys from both tables; LEFT JOIN preserves every row from the left table even when a match is missing.
  • RIGHT JOIN is the mirror of LEFT JOIN, while FULL OUTER JOIN is useful for reconciliation because unmatched rows from both sides remain visible.
  • Duplicate join keys can multiply rows, so key cardinality should be checked before trusting aggregates.
  • The correct join depends on the population you want to preserve, not on which syntax is shortest.

Work through a query with row-count checks

For SQL Joins, predict one visible result before each snippet runs—a row count, shape, statistic, ranking or error pattern—then compare it with the printed checkpoint.

Example 1 · Baseline example
-- SQL Joins · example 1
SELECT c.customer_id, c.city, o.order_id, o.amount
FROM customers c
LEFT JOIN orders o
  ON c.customer_id = o.customer_id;
Output / checkpoint
SQL Joins checkpoint 1: Run the cell and inspect the printed values before changing anything.
Example 2 · Confirm table grain
-- SQL Joins · example 2
SELECT COUNT(*) AS rows, COUNT(DISTINCT customer_id) AS customers
FROM practice_orders;
Output / checkpoint
SQL Joins checkpoint 2: rows | customers
30   | 12
Example 3 · Inspect duplicate keys
-- SQL Joins · example 3
SELECT customer_id, COUNT(*) AS n
FROM practice_orders
GROUP BY customer_id
HAVING COUNT(*) > 1
ORDER BY n DESC;
Output / checkpoint
SQL Joins checkpoint 3: Customers with more than one row are listed before any join or aggregation.
Example 4 · Validate a grouped result
-- SQL Joins · example 4
SELECT region, COUNT(*) AS orders, ROUND(SUM(amount),2) AS revenue
FROM practice_orders
GROUP BY region
ORDER BY revenue DESC;
Output / checkpoint
SQL Joins checkpoint 4: region | orders | revenue
West   | ...    | ...
Example 5 · Compare detail and aggregate totals
-- SQL Joins · example 5
WITH x AS (
  SELECT amount FROM practice_orders WHERE amount IS NOT NULL
)
SELECT ROUND(SUM(amount),2) AS detail_total,
       ROUND((SELECT SUM(amount) FROM x),2) AS check_total
FROM x;
Output / checkpoint
SQL Joins checkpoint 5: detail_total and check_total should match exactly.

Test duplicates, NULLs and unmatched keys

Verification habit

Duplicate join keys can multiply rows, so key cardinality should be checked before trusting aggregates.

Failure mode to watch

The correct join depends on the population you want to preserve, not on which syntax is shortest.

Self-check with answers

For SQL Joins, what result should you be able to explain without the code?

INNER JOIN keeps matched keys from both tables; LEFT JOIN preserves every row from the left table even when a match is missing.

Which assumption matters most in this SQL Joins exercise?

Duplicate join keys can multiply rows, so key cardinality should be checked before trusting aggregates.

What failure mode would make this SQL Joins result untrustworthy?

The correct join depends on the population you want to preserve, not on which syntax is shortest.

Practise with a reproducible SQLite-style dataset

Try it yourself workspace

Edit this SQL Joins starter, copy it, and run it in the downloadable notebook or your local Jupyter environment.

Questions specific to this lesson

When should I use join behavior in an analysis?

INNER JOIN keeps matched keys from both tables; LEFT JOIN preserves every row from the left table even when a match is missing.

What row-count check should I do before trusting the result?

Duplicate join keys can multiply rows, so key cardinality should be checked before trusting aggregates.

What is the most common beginner mistake here?

The correct join depends on the population you want to preserve, not on which syntax is shortest.

How can I practise this without a production database?

Use the CSV and notebook in this lesson, load the file into SQLite or pandas, predict the row count first, then compare your result with a simpler query.

Primary references and further reading

For SQL Joins, use these primary references when exact syntax, defaults or formal definitions matter beyond the examples on this page.

AK
Written by Ashok Kumar Yadav

Ashok Kumar Yadav writes Xenors tutorials on applied AI, programming and data workflows. This SQL Joins lesson is designed as a reproducible learning exercise rather than a keyword-first article.

GitHub · LinkedIn

Continue exploring