SQL Joins: Combining Data Across Tables

Introduction
Real databases rarely keep everything in one table — driver details, ride records, and route information usually live separately to avoid duplication. Joins are how SQL brings related data back together across those tables in a single query.

What Are Joins?
A join links rows from two (or more) tables based on a shared column — usually an ID that appears in both. Without joins, I'd have to look up related information manually, one table at a time.
Types of Joins
INNER JOIN — returns only rows that match in both tables.

LEFT JOIN — returns everything from the left table, plus matches from the right; unmatched right-side rows show as NULL.

RIGHT JOIN — the mirror of LEFT JOIN: everything from the right table, plus matches from the left.

FULL OUTER JOIN — combines LEFT and RIGHT: everything from both tables, matched where possible, NULL where not.

When to Use Each

• INNER JOIN — when I only care about complete, matched records (e.g., "show me fares for drivers who actually have bookings").
• LEFT JOIN — when I need everything from my main table, even if some rows have no related data (e.g., "show me every driver, including those with zero bookings").
• RIGHT JOIN — functionally the same as LEFT JOIN with tables swapped; I rarely use it directly, since writing a LEFT JOIN with tables in the right order is usually clearer to read.
• FULL OUTER JOIN — when I need to audit for mismatches on both sides at once (e.g., finding bookings with no valid driver, and drivers with no bookings, in a single result).

What I Learned
The concept that took the most practice was realizing that a join isn't really "combining tables" in general — it's about deciding what happens to unmatched rows on each side. Once I started asking "what do I want to happen to rows without a match" for every join I wrote, choosing between INNER, LEFT, RIGHT, and FULL OUTER became a matter of answering that one question rather than memorizing four separate syntaxes.