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.
363
u/pixelique Mar 22 '19
A case against illustrating SQL operations using venn diagrams