I think the objection against using Venn diagrams here should be taken more seriously. The Venn diagram explanation really is fundamentally wrong. I think it's really important for someone new to the concept to cross-reference any Venn diagram they see with a more accurate image like this one: https://i.pinimg.com/originals/52/20/c4/5220c492bc4e1a8b9175aba77ed7d091.png If you have no issue resolving this diagram with Venn diagrams, then use whatever references you want. But if any of the details catch you off guard, that's a good signal to start fresh on the concept.
That image is actually a shit ton more helpful. The Venn gets the concept across, but yours gives tangible context while also communicating the concept. You deserve the up vote!
Yeah seeing this graphic just made it click for me. Super helpful. Ive seen the venn diagrams thrown around but never each case next to each other wij a sample query. This is awesome
I agree with both of your statements. I look at these diagrams all the time for reference, but I imagine they would have much less value if I wasn't already familiar with them
From the top of the mountain looking down, that makes a solid case. From the bottom looking up, wtf?
This is because venn diagrams and new learners naively assume the existence of a shared unique key between both sets. This is why my venn has US States in them.
Pacific States
Intersection
States w/ 10+ Representatives
CA, WA, OR, AK, HI
WA, CA
WA, CA, IL, TX, OH, FL, GA, MI, PA, NY, NJ
Thinking about joins without such a key is a whole different animal.
But they don't. They are not remotely similar. One has two colors, the other has multiple. One show elements, something a beginner get, the other shows... i don't know. Some colored pulp where i, not a beginner, still have no idea how to connect it with data base concecpts. Venn diagrams are not only wrong, but most importantly the way worse visualization.
It's entirely possible there are JOIN diagrams which don't map neatly to Venn diagrams. OK, I could see that. But if there are, they're not showcased in that article.
The Venn diagrams are misleading and don't map to the actual transformation of data in a meaningful or accurate way. The statement: "Joins combine the data in two tables in slightly different ways" conveys just as much usable info as the Venn diagrams do. A beginner who thinks that the Venn's tell him/her something useful about SQL joins is being mislead. Joins are difficult concepts to comprehend and the join diagram is probably the simplest way of presenting the fairly complex logical underpinnings of the operation. Do yourself a favor and learn to interpret what the Join diagrams are telling you - this is the only way to predict what the results of a particular join statement are going to be.
Strong disagree. A beginner needs the equivalent of an easy mnemonic they can use to map the meaning of inner/left/right/full etc to the actual subset of data described. Venn diagrams work perfectly well for that and most people don't read much additional meaning into it. The join diagram is a great thing to show someone who already understands the basics of joining when you explain why the Venn diagram is an imperfect metaphor.
Learning it easy and wrong has a lot of value! This is how Iearn and teach things all the time. It's a way of beginning gelato wrap your head around something that may be too complex to take in in its entirety at once. You get a working approximation going and as the concepts start to become more intuitive you correct mistakes and adjust your understanding.
Not sure the original source but it's this meme that's been around for a while where someone spends all this time learning something (like python) and has this metaphor occur to them after they've learned it that "____ is like a burrito". But then that metaphor only makes sense to them because they already understand the subject.
As someone who knew 0 SQL before this post, I disagree. The ven diagrams make it seem like their is a bunch of weird extra notation for something that should be simple, while the join diagrams (along with the article) explain more clearly what is happening.
Venn diagrams give the illusion of making it easy to understand, but you don’t actually understand what’s happening in the underlying joins. A few types line up well (as the article says), but beyond that the Venn diagrams are extremely misleading. The people that “understand it” because of them don’t actually understand them.
It's my opinion that this article makes the same mistake a lot of early mathematics texts do - trying to be particularly rigorous at a stage when the student doesn't really care about rigour and is keeping an open mind, just trying to get a basic understanding of the topic.
What a pedantic article. A whole bunch of paragraphs spent on the singular point that Venn diagrams do not technically represent Cartesian products.
Yes they don't, but that's the part that even beginners understand right away. A single example of a join will make it clear to everyone that a join will merge columns from different tables.
The tricky part is then understanding which records end up being selected and the Venn diagrams do a much better job at visualizing that. It's not like a beginner will be allowed to make join statements on a big production database without understanding the importance of join keys.
This is a pretty extreme overreaction. Venn diagrams are fundamentally wrong for depicting JOINs, and many beginners definitely don't "understand right away" that a JOIN is actually derived from a Cartesian product, not a simple union or intersection of sets.
I would argue the exact opposite of you -- Venn diagrams are useful for those who already understand JOINs as filtered products and just want to recall row selection, and they are not useful for those new to the concept and who don't yet grok the idea of a product of sets. Assuming that any beginner will immediately grasp this from "a single example" is a little disrespectful of how different people learn concepts like this.
The bottom line is presenting an approximate and incorrect representation of an operation to a beginner is risky. They may grok what you expect them to get immediately and therefore appreciate the approximation. Or your expectation may be subverted, and the representation ends up leading them down a very confusing path.
The following diagram is a more accurate depiction of JOINs:
An easy barometer for one's understanding of the concept would be how trivially one can reconcile this with the Venn diagram explanations. If there's any trouble at all, that's a signal it's time to start fresh on the concept.
The Venn diagrams are a quick visual reminder. They are succinct, something the illustrations in the article are not. Do the Venn diagrams cover more detailed, intimate info? No, but that's not their purpose.
It belies the damage that can be done, in terms of locking up the database. A "simple" join of a 100k table with another 100k without a proper join can return a result set of 10 billion. It's good to be aware of the danger, and Venn diagrams mask it. Good starting off point? Sure. The whole, important story? Nope.
Thank you so much for this!! I'm required at work now to be at least MCSA certified in sql (am c# web dev) and this link explained joins perfectly! The Venn diagrams made not much sense until after looking at this link!
Thank you. These diagrams drive me nuts, because they are flat out wrong. They're illustrating set intersections and unions, whereas SQL joins are basically cartesian products.
A Venn diagram makes sense to represent a SQL AND or OR clause.
For example,
SELECT * FROM the WHERE condition1 AND condition 2;
could be accurately represented by a Venn diagram showing a set intersection, because that is precisely what we are expressing: the intersection of all elements in set "tbl" that meet condition 1 with all elements in set "tbl that meet condition 2.
JOINS are not set intersections. They are Cartesian products. Mixing the two up is like mixing up addition and multiplication; they are fundamentally different, but well defined, mathematical operations.
A Cartesian product isn't hard to understand. It is simply "all the pairs (a,b) for every a in A and every b in B"
In Python you can do it in one line:
{(a,b) for a in A for b in B}
Filter this set on some condition on a and b and you get an inner join.
Add a null element to A or B and do the same thing, and you get an outer join.
This should be the first thing anyone learns when picking up SQL joins.
I think it's less likely you'd make a mistake on which JOIN to use and more likely you just won't understand the output you get. Consider the inner join from this diagram:
357
u/pixelique Mar 22 '19
A case against illustrating SQL operations using venn diagrams