Your First JOIN – Connecting Customers to Their Bookings

Hello ,

Imagine this: Your marketing manager walks up and says, “I need to see what expeditions Emily Rodriguez has booked with us. Can you pull that?”

You have their customer database. You have their bookings database. But the customer name is in one table and the booking details are in another.

Most beginners panic here. “How do I connect these tables?”

Confident analysts? They write one JOIN query and get the answer in 30 seconds.

This is the skill that unlocks almost everything in business analytics. Let me show you how simple it actually is.

The Business Problem

Your company has customer information in one table:
Names
Email addresses
Phone numbers
Experience levels

And booking information in a different table:
Booking dates
Expedition names
Prices
Status

They’re connected by one thing: customer_id.

Your job is to bring them together.

The Query That Connects Them

Here’s what I ran against the Summit Adventures database (the fake adventure tourism company I created to help people learn business analytics):

-- Show a customer's complete booking history
SELECT 
    c.first_name || ' ' || c.last_name AS customer_name,
    c.email,
    c.experience_level,
    e.expedition_name,
    b.booking_date::date AS booked_on,
    b.status AS booking_status,
    p.amount AS amount_paid
FROM customers c
    INNER JOIN bookings b ON c.customer_id = b.customer_id
    INNER JOIN expedition_instances ei ON b.instance_id = ei.instance_id
    INNER JOIN expeditions e ON ei.expedition_id = e.expedition_id
    LEFT JOIN payments p ON b.booking_id = p.booking_id 
        AND p.payment_status = 'completed'
WHERE c.email = 'mlaurent903@university.edu'
ORDER BY b.booking_date DESC;

Here’s what we found for Michelle Laurent:

Customer: Michelle Laurent, Expert experience level
6 total bookings spanning 2024-2025
3 completed expeditions: Wilderness Wildlife Tour ($2,893), Landscape Lens Workshop ($954), Landscape Lens Workshop ($749)
3 cancelled: Landscape Lens Workshop, Indigenous Peoples Tour (twice), Mountain Vista Trek
Total spent: $4,596 on completed bookings

The insight:

Michelle is a high-value expert customer who has spent over $4.5K but shows a concerning pattern—50% cancellation rate across 6 bookings. Her completed trips span safari and photography categories. Marketing should:
Focus on safari and photography offerings (proven interests)
Investigate cancellation reasons (scheduling conflicts? Better competitor offers?)
Implement retention strategy for this high-value but at-risk customer segment

Breaking Down The JOIN

Line 10: The First Connection

INNER JOIN bookings b ON c.customer_id = b.customer_id

This says: “For every customer, show me their bookings where the customer_id matches.”

Think of it like matching puzzle pieces. The customer_id is the edge that connects customers to bookings.

Lines 11-12: The Second Connection

INNER JOIN expedition_instances ei ON b.instance_id = ei.instance_id
INNER JOIN expeditions e ON ei.expedition_id = e.expedition_id

Now we’re going deeper. Each booking connects to a specific trip instance, and each instance connects to the expedition details (name, type, description).

This is like following a trail: Customer → Booking → Trip Instance → Expedition Details

Line 13: The Optional Connection

LEFT JOIN payments p ON b.booking_id = p.booking_id

Notice this says LEFT JOIN, not INNER JOIN. That’s because some bookings might not have payments yet (or were cancelled before payment).

LEFT JOIN says: “Show the booking even if there’s no payment.” INNER JOIN would only show bookings that have payments.

Why This Pattern Works Everywhere

This is the exact pattern you’ll use at almost every company:

E-commerce:

FROM customers c
    INNER JOIN orders o ON c.customer_id = o.customer_id
    INNER JOIN order_items oi ON o.order_id = oi.order_id

SaaS:

FROM users u
    INNER JOIN subscriptions s ON u.user_id = s.user_id
    INNER JOIN subscription_plans sp ON s.plan_id = sp.plan_id

Retail:

FROM customers c
    INNER JOIN purchases p ON c.customer_id = p.customer_id
    INNER JOIN products pr ON p.product_id = pr.product_id

The structure stays the same. You’re following the relationships from one table to the next.

The KEY Concept (Literally)

Every table has a unique identifier (usually something like customer_id, booking_id, product_id).

When that same field appears in another table, it’s called a foreign key – it’s the connection point.

Look for these patterns:
customers.customer_id = bookings.customer_id
bookings.booking_id = payments.booking_id
expeditions.expedition_id = expedition_instances.expedition_id

These are the puzzle edges that let you connect tables.

Common Beginner Mistakes

Mistake #1: Forgetting the ON clause

-- WRONG - This creates a mess
INNER JOIN bookings b

You must tell SQL HOW to connect the tables:

-- RIGHT
INNER JOIN bookings b ON c.customer_id = b.customer_id

Mistake #2: Using INNER JOIN when you need LEFT JOIN

INNER JOIN only shows rows where BOTH tables have matching data.
LEFT JOIN shows all rows from the first table, even if the second table has no match.

If you want to see customers who haven’t booked anything yet, you need LEFT JOIN.

Mistake #3: Not using table aliases

When you have multiple tables, always use aliases (c, b, e, p):

FROM customers c

This makes your query readable. Otherwise you’re typing `customers.customer_id` everywhere instead of `c.customer_id`.

Try This Right Now

Open your company database. Find two related tables (usually connected by an ID field).

Try this pattern:

SELECT 
    table1.some_column,
    table2.some_column
FROM table1
    INNER JOIN table2 ON table1.id_field = table2.id_field
LIMIT 10;

Replace:
`table1` with your first table name
`table2` with your second table name
`id_field` with the matching column (like customer_id, order_id, etc.)

You’ll see the two tables connected. That’s your first JOIN.

Why This Skill Matters

JOINs are how you answer 80% of business questions:
“Show me which customers bought which products”
“Which sales reps closed which deals?”
“What subscriptions do our enterprise customers have?”

All of these require connecting multiple tables. Once you understand the pattern, it becomes second nature.

Building Confidence, One Query at a Time

Here’s the truth: JOINs feel scary until you write your first successful one.

I spent months avoiding multi-table queries. Every time a manager asked for analysis requiring multiple data sources, I’d freeze. “I’ll get back to you,” I’d say, then spend hours Googling and trying random approaches.

Then one day, it clicked. A colleague showed me: “It’s just matching IDs, like connecting dots.”

That simple reframe changed everything.

I wrote my first successful 3-table JOIN. Then a 4-table JOIN. Within weeks, I was writing them like it was nothing.

The imposter syndrome around JOINs didn’t disappear because I memorized syntax. It disappeared because I understood the concept: tables connect through matching IDs. That’s it.

Once you understand that, JOINs become second nature.

You can learn this too. Start with two tables. Get comfortable. Then add a third. Before long, you’ll wonder why it ever seemed hard.

Until next time,
Brian ([say hi on twitter!](https://twitter.com/briangraves))

—

P.S. This is exactly how I teach SQL in SQL for Business Impact – starting with simple patterns that build confidence, then progressing to complex multi-table analysis. You don’t need to be a developer or have a technical background. You just need a clear, step-by-step approach. If you’re ready to stop feeling intimidated by SQL and start feeling confident, check out [sqlforbusinessimpact.com](https://sqlforbusinessimpact.com).

P.P.S. Try writing your first JOIN this week and hit reply to tell me what you found. Celebrating small wins is how we build confidence. I read every response.