Hacker News Reader

Comment by obeattie | Hacker News Reader

Honestly, if it were not for Venn diagrams, I may have never learned how SQL joins work. It might not be perfect, but if you'd tried to make 16-year-old me understand relational algebra in order to grok how the joins in his Django site were working, he'd have given up before he began.

That's not to say that other ways of illustrating things don't have merit, but broad statements like "say NO to Venn diagrams" just aren't helpful. If people find Venn diagrams a useful tool (and their proliferation indicates they do), I don't see the harm. They didn't stop me going deeper on stuff like relational algebra when I was ready to.

View on HN

Venn diagrams are almost, but not quite, completely wrong. They hint at the idea of including failed joins vs only successful joins, but this is only a small part of the full logic behind Cartesian product + filter - even if it's the most commonly used pattern in practice in most database models that ultimately get used in an object oriented programming language.

I think it's OK to use the venn diagram only as an explanatory tool, briefly, and informally. If you raise it to the level of a complete description of semantics, then it's very inadequate. Any step off the beaten path, where the cardinality of the join is no longer 1:1 or 1:n, and you're back in the weeds again.

The thesis is Say no to Venn diagrams for Joins.

The first section is about how Venn works fine for AND and OR because it’s set theory and Venn works just fine for examples (maybe not every problem though).

Joins are not sets. They are Cartesian products.

I'll be honest: if I didn't know SQL already, I would have no idea what his diagrams are trying to convey...

I do know at this point that he is technically right... But being 100% correct doesn't really matter at the beginning.

And Venn diagrams are right enough to start working with joins

That may be a fair critique. Should SQL be successful only to mathematicians and computer scientists? (Who else would even know about set theory or Venn a priori?)

In my underfunded rural American elementary school, they taught us Venn diagrams. Not set theory per-se, but they taught us to read and create Venn diagrams.

I don't know if that's representative, but my gut instinct is that Venn diagrams are very accessible to the general public.

A cross join is the union of 3 mutually exclusive sets: the left join tuples, the inner join tuples, and the right join tuples. Is this not the case? So then you can use Venn diagrams just fine.

Um no. The left and right joins both include the inner join tuples; they are not mutually exclusive. A cross join is the Cartesian product of two sets, which means it doesn't include the outer join tuples.

Ok I should have been more precise. By "left join tuples" I intended to mean the "left join - inner join" tuples. The point is you can use sets and Venn diagrams to talk about joins.

You're language is still not quite right. A cross product does not include those parts of the outer joins. An inner join is a subset of a cross product, but an outer join includes elements not in either. What you say would be true of a full outer join, but not a cross product. If one circle in the Venn diagram represents the left join and one circle right join, then the Venn diagrams would be correct but not if the circles represent separate tables.

Maybe you didn't read the article? He presents a pretty nice visual alternative to Venn diagrams.

I did read the article and I don't find what the author thinks is a "nice illustration of a cartesian product" easy to grok at all. Similarly, I think I would have found the the diagrams further down hard to understand versus a Venn diagram.

But that wasn't my point; if other people find these illustrations helpful, that's awesome and I wouldn't want to stop someone inventing something new and useful. My point was that I violently disagree with one-size-fits-all proclamations like "Say NO to Venn Diagrams."

The hardest part of joins is remembering which is which. Venn diagrams are used specifically because they solve that problem with the inner/outer/left/right terminology.

His visualizations ultimately help nothing. You have to stare at them for a while to see what the pattern is, but there's absolutely no mnemonic hook to remember what's what, so in the end all you learn from his visualizations are that there exist different ways to slice and dice the products of sets, which is already a given if you're trying to figure out what the differences are.

The author's diagrams aren't perfect either, but I think they are much more clear to novice coders about the real workings of joins.

Check this out, similar to the author's approach, but animated. This is the best visual of SQL joins I've ever found. https://news.ycombinator.com/item?id=16983007

For me, I still have no idea what the visual of a venn diagram is trying to tell me within the context of SQL. Just having a visual that I can't even understand does nothing to benefit the situation either.

Reply on news.ycombinator.com