Yes. And, having taught SQL to Excel power users, I can tell you it is a very effective learning model.
The "filtered cross-join" model allows students who have learned SELECT and WHERE to think of a JOIN as an extension of those primitives, a combination of two tables on which they can filter.
Venn diagrams might be useful to visualize an outcome, but they will not support stepping through primitives to a solution.
In "filtered cross-join", JOIN can be an extension of SELECT that combines two tables. The combination is a set of rows, each each of which combines all the fields of one row of one table with all the fields of one row of the second. This is easily visualized with two two-column tables of three rows.
They can then use WHERE to find those rows with matches on the key field.
With this model, students can build up JOIN as an abstraction of simpler primitives. When they are struggling with a problem, you can ask them to first step through those primitives to accumulate the solution. Say, query the "raw" join and examine a few rows to see which they want returned. What is true of those and not true of the ones you do not want? ("I want those where these two fields match, and none that do not.") Ok, how do you express that condition in SQL? ("Where . . . this equals that?" "Hmm, try that" "HEY THAT WORKED!")
With that basis, they have a model that can extend to more complexity -- joins across several tables, joins on the same table, joins with conditions other than field equality.
Building up to and using this model, you can have the vast majority of students writing joins with confidence in two days.
My suggestion to the site would be, use an example that has two columns on each table, to provide the key field on which the join will be performed.
The "filtered cross-join" model allows students who have learned SELECT and WHERE to think of a JOIN as an extension of those primitives, a combination of two tables on which they can filter.
Venn diagrams might be useful to visualize an outcome, but they will not support stepping through primitives to a solution.
In "filtered cross-join", JOIN can be an extension of SELECT that combines two tables. The combination is a set of rows, each each of which combines all the fields of one row of one table with all the fields of one row of the second. This is easily visualized with two two-column tables of three rows.
They can then use WHERE to find those rows with matches on the key field.
With this model, students can build up JOIN as an abstraction of simpler primitives. When they are struggling with a problem, you can ask them to first step through those primitives to accumulate the solution. Say, query the "raw" join and examine a few rows to see which they want returned. What is true of those and not true of the ones you do not want? ("I want those where these two fields match, and none that do not.") Ok, how do you express that condition in SQL? ("Where . . . this equals that?" "Hmm, try that" "HEY THAT WORKED!")
With that basis, they have a model that can extend to more complexity -- joins across several tables, joins on the same table, joins with conditions other than field equality.
Building up to and using this model, you can have the vast majority of students writing joins with confidence in two days.
My suggestion to the site would be, use an example that has two columns on each table, to provide the key field on which the join will be performed.