The Visual Guide to SQL Joins

Inner Join

From the Linkskill Academy visual SQL joins journal — page 02/08.

What it does: returns only the rows where the join column matches in both tables. If a row in either table has no match, it's left out of the result completely.

Think of it like: "Show me only the matches."

SELECT e.EmpID, e.Employee, d.Department
FROM   Employee e
INNER JOIN Department d
  ON   e.DeptID = d.DeptID;

Result (Inner Join)

Notice what's missing: Divya (no DeptID at all) and Eshan (DeptID 40 doesn't exist in Department) are both dropped. So is Marketing — no employee belongs to it. Inner Join only keeps rows where both sides agree.

Left Join

From the Linkskill Academy visual SQL joins journal — page 03/08.

What it does: keeps every row from the left table (the one listed right after FROM), and attaches matching data from the right table wherever it exists. Where there's no match, the right-hand columns come back as NULL.

Think of it like: "Keep left, add right if available."

SELECT e.EmpID, e.Employee, d.Department
FROM   Employee e
LEFT JOIN Department d
  ON   e.DeptID = d.DeptID;

Result (Left Join)

All 5 employees are present this time — Divya and Eshan just get NULL instead of a department name, since neither has a matching DeptID. Marketing still doesn't appear anywhere, because Left Join only protects rows from the left table.

Right Join

From the Linkskill Academy visual SQL joins journal — page 04/08.

What it does: the mirror image of Left Join — keeps every row from the right table, and attaches matching data from the left table wherever it exists.

SELECT e.EmpID, e.Employee, d.Department
FROM   Employee e
RIGHT JOIN Department d
  ON   e.DeptID = d.DeptID;

Result (Right Join)

This time Marketing shows up (with NULL employee columns, since nobody belongs to it), while Divya and Eshan disappear entirely — they have no department, so they're not protected by a Right Join.

Full Outer Join

From the Linkskill Academy visual SQL joins journal — page 05/08.

What it does: returns everything — matched rows, left-only rows, and right-only rows, all in one result set. Anywhere there's no match, the missing side comes back as NULL.

Think of it like: matched + left-only + right-only, combined.

SELECT e.EmpID, e.Employee, d.Department
FROM   Employee e
FULL OUTER JOIN Department d
  ON   e.DeptID = d.DeptID;

Result (Full Outer Join)

Every employee and every department appears somewhere — nothing is dropped. This is the join to reach for when you're auditing data quality and need to see every mismatch in both directions at once.

Cross Join

From the Linkskill Academy visual SQL joins journal — page 06/08.

What it does: pairs every row in the first table with every row in the second table. There's no matching key at all — it's pure multiplication. 3 rows × 3 rows = 9 rows out.

SELECT e.Employee, d.Department
FROM   Employee e
CROSS JOIN Department d;

Result (3 employees × 3 departments = 9 rows)

Self Join

From the Linkskill Academy visual SQL joins journal — page 07/08.

What it does: joins a table to itself, using two different aliases so SQL can treat one table as if it were two. This is the standard way to model hierarchies — most commonly, employees and their managers, where the manager is also a row in the same Employees table.

Think of it like: one table can play two roles at once.

Employees

ManagerID simply points to another row's EmpID in the same table — that's the whole trick behind a self join.

SELECT e.Employee AS EmployeeName,
       m.Employee AS ManagerName
FROM   Employees e
LEFT JOIN Employees m
  ON   e.ManagerID = m.EmpID;

Result

Asha has no manager (she's at the top), so her row correctly returns NULL — using a Left Join here means she still appears, instead of being silently dropped by an Inner Join.