If you’ve ever worked with relational databases, you know that most data doesn’t live in a single table. That’s where JOINs come in. They let you connect data across multiple tables to create a complete story.
During my undergrad, I remember learning the different joins in one of my classes and I was just like:
But in this post, I’m going to break down the four most common JOIN types in a fun and easy way. If you’re an analyst and job skills mention SQL, these are essential to your success! But before I do, I want to cover Table Aliases.
table aliases
When you’re working with joins, table names can get long and repetitive. That’s where aliases come in.
WHAT’S AN ALIAS?
An alias is just a nickname for a table that makes your query shorter and easier to read.
For example, instead of writing:
SELECT customers.customer_id, customers.first_name, orders.order_id
FROM customers
JOIN orders
ON customers.customer_id = orders.customer_id;
Aliases become a game-changer and you can instead write:
SELECT c.customer_id, c.first_name, o.order_id
FROM customers AS c
JOIN orders AS o
ON c.customer_id = o.customer_id;
Here, I’ve given customers the alias c and orders the alias o.
- c stands for Customers
- o stands for Orders
This way, the query is cleaner and it’s easier to see which table each column comes from.
✨TIPS
- CONSISTENCY IS KEY: Always use the same alias convention so others can follow your queries.
- KEEP IT INTUITIVE: Use short, obvious letters like c for customers, o for orders, p for products.
- IMPROVES READABILITY: Especially helpful when you join 3+ tables.
Now, let’s get into the meat of this post!
1. inner join
the matchmaker.
USE CASE: Return only the rows that exist in BOTH tables.
CODE SNIPPET:
SELECT c.customer_id, c.first_name, o.order_id, o.order_date
FROM customers AS c
INNER JOIN orders AS o
ON c.customer_id = o.customer_id;
RESULTS: Only the customers who have placed orders. Anyone without an order gets excluded.
2. left join
EVERYTHING FROM THE LEFT
USE CASE: Keep all rows from the left table, and match data from the right if it exists.
CODE SNIPPET:
SELECT c.customer_id, c.first_name, o.order_id
FROM customers AS c
LEFT JOIN orders AS o
ON c.customer_id = o.customer_id;
RESULTS: A list of every customer — even those who haven’t placed an order yet. Missing values from the right table will show as NULL.
3. right join
EVERYTHING FROM THE RIGHT
USE CASE: The mirror of LEFT JOIN. Keep all rows from the right table, and match data from the left if possible.
CODE SNIPPET:
SELECT c.customer_id, c.first_name, o.order_id
FROM customers AS c
RIGHT JOIN orders AS o
ON c.customer_id = o.customer_id;
RESULTS: You’ll see every order in the system — even if the customer record is missing (maybe due to data entry issues).
4. full outer join
THE UNION OF BOTH
USE CASE: Return all rows from both tables, with matches.
CODE SNIPPET:
SELECT c.customer_id, c.first_name, o.order_id
FROM customers AS c
FULL OUTER JOIN orders AS o
ON c.customer_id = o.customer_id;
RESULTS: This shows every customer and every order, whether or not they match. It’s the widest view — useful for finding gaps in data where possible.
Visual Summary
- INNER JOIN: Only matches
- LEFT JOIN: Everything from the left + matches
- RIGHT JOIN: Everything from the right + matches
- FULL OUTER JOIN: Everything from both sides

wrapping up
I hope you enjoyed this little lesson on SQL Joins!
Remember, JOINS are the glue of SQL. Mastering them will allow you to:
✅ Combine multiple datasets into one view
✅ Identify gaps and mismatches
✅ Build richer insights for business questions
Next time you’re writing a query, think: Do I need just the matches, or everything from one side (or both)?
That answer will guide which JOIN you use.
💡 CONFESSION TIME: I didn’t fully understand JOINs until I had to write complex queries in the real world. In my next post, I’ll share how JOINs finally “clicked” for me — and why it’s normal if they still feel confusing at first.
👉 In a future post, I’ll share how JOINs came together for me — and why it’s completely normal if you don’t feel 100% confident with them yet.
Until next time,
Ardonna •ᴗ•
author’s note
Hi, I’m Ardonna Cardines — a data analyst and creator of Mercury Musings, where business meets imagination through data. I love blending analytics, design, and storytelling to make learning data modeling and visualization approachable — one creative dataset at a time.
If you’ve enjoyed this post, I’d love for you to follow along.
You can subscribe to my blog for new tips + tutorials, creative datasets, and behind-the-scenes projects — or connect with me on LinkedIn where I share updates and learning resources for analysts and data storytellers.
