Skip to main content

📝 Latest Blog Post

Stop Using Venn Diagrams for SQL Joins: The "Row Filter" Mental Model

Stop Using Venn Diagrams for SQL Joins: The "Row Filter" Mental Model

Stop Using Venn Diagrams for SQL Joins: The "Row Filter" Mental Model

The most common way SQL is taught is also the most misleading. It's time to delete the circles from your brain and start thinking in rows.

If you learned SQL in a bootcamp or a university, you were almost certainly shown a Venn Diagram. You know the one: two intersecting circles labeled "Table A" and "Table B." The intersection is labeled "Inner Join."

Here is the problem: SQL is not Set Theory.

When you rely on Venn Diagrams, you start to think of tables as sets of objects. But when you write a query and half your customer data vanishes, the Venn Diagram doesn't explain why. It doesn't explain duplication. It doesn't explain NULL values.

The Truth: A Venn Diagram implies that an Inner Join only returns the unique intersection. In reality, SQL Joins can multiply rows, duplicate data, and create nulls. The circles are a lie.

The Better Mental Model: Filters & Matches

Instead of circles, I want you to visualize two spreadsheets side-by-side. One is on the Left, and one is on the Right. The Join type you choose determines which rows get deleted and which rows get kept.

1. INNER JOIN (The Exclusive Club)

Think of an INNER JOIN as a bouncer at a club. It is exclusive.

The query looks at Row 1 from the Left Table. It asks: "Do you have a match in the Right Table based on the ID?"

  • Yes? The row is kept.
  • No? The row is deleted immediately. It does not appear in your results.

This is why beginners lose data. If you INNER JOIN your "Customers" table with your "Orders" table, any customer who hasn't placed an order yet simply disappears from your report. They are kicked out of the club.

SELECT * FROM Customers INNER JOIN Orders ON Customers.ID = Orders.CustomerID; -- Result: Only Customers WITH Orders.

2. LEFT JOIN (The Inclusive Host)

Think of a LEFT JOIN as an inclusive host. It prioritizes the Left Table (the first one you mention).

The query looks at Row 1 from the Left Table. It asks the same question: "Do you have a match in the Right Table?"

  • Yes? Great, bring in the data from the Right table.
  • No? That's okay. Keep the row from the Left table anyway, and just put NULL (empty blanks) where the Right table data should be.

This is crucial for analysis. If you want a list of all your customers, and you want to see their orders if they have them, you must use a Left Join.

SELECT * FROM Customers LEFT JOIN Orders ON Customers.ID = Orders.CustomerID; -- Result: All Customers. Non-buyers show NULL in order columns.

Comparison: Why Venn Diagrams Fail Here

If you have a customer who placed 5 orders, an INNER JOIN will return that customer's name 5 times (once for each order). A Venn Diagram cannot visualize this "row multiplication." It just shows an intersection.

Feature INNER JOIN LEFT JOIN
Mental Model Exclusive (Must Match) Inclusive (Keep Left)
Unmatched Rows Deleted / Hidden Kept with NULLs
Use Case Finding commonality Auditing / Complete Lists

Conclusion

Stop drawing circles. Start thinking about the flow of data rows.

  • Use INNER JOIN when you only want data that exists in both worlds.
  • Use LEFT JOIN when you want to preserve your main list (Left) regardless of whether extra data (Right) exists.

By shifting your perspective from geometry to data filtering, you will stop writing queries that accidentally delete half your business intelligence.

Download SQL Joins Visual Cheat Sheet

Comments

🔗 Related Blog Post

🌟 Popular Blog Post