Sql JOINS and the Sql Server Management Studio Query Designer

4.31 (29 votes)

There are a whole bunch of articles, blog entries and tutorials that seek to explain how SQL JOINS work. Some of them are excellent, and others are just confusing. The reason I am adding my go at trying to clarify JOINS to the mix is to highlight how proper use of the tools available to you can seriously reduce the chances of getting the JOIN syntax or type wrong. Since JOINS are all about how to relate data from one table to another, I thought it appropriate to illustrate the subject using Parents and Children (who may, or may not be related to eachother). So let's meet the families.

Peter has 2 children: Jo and Roger
Mary has 1 child: Susan
Alice has 2 children: Kevin and Rachel
John has 1 child: David
Jimmy has no children.
Sam and Ian have no parents. They are orphans.

This is how they appear in database tables: Parents and Children. Children are related to Parents by the AdultID.

INNER JOIN - All parents with children

If we open up the Query Designer in Sql Server Management Studio, and add the 2 tables, they are joined on the AdultID by default using an INNER JOIN. If they are not automatically joined (by the line that appears between the tables) you have not set AdutlID in the Children table as a foreign key. However, you can simply drag AdultID in the Children table, and drop it onto the AdultID in the Parents table to create the relationship.

Selecting AdultName and ChildName in the repsective columns generates the following SQL:

And when the SQL is executed, all parents with children are returned:

So who's missing? Batchelor Jimmy is nowhere to be seen (because he has no children) and nor are our orphans, Sam and Ian. INNER JOIN only returns rows from the two tables where there are matches based on the JOIN-predicate, which in this case is where Parents.AdultID has a matching record in Children.AdultID.

LEFT OUTER JOIN - All Parents, and their children if they have any

Right-clicking on the diamond in the middle of the Join line in the query designer reveals a context menu with some options for the JOIN. If we select "Select All Rows from Parents", the left hand side of the diamond fills out, and some new SQL is generated:

When this is executed, the LEFT OUTER JOIN returns all the parents (including Jimmy), irrespective of whether they have children or not:

It also returns all the children that have parents. In the case of Jimmy, he has NULL against the ChildName column, because he has no children.

RIGHT OUTER JOIN - All children, and their parents if they have any

We deselect "Select All Rows from Parents", and select "Select All Rows from Children" instead. The right hand side (or perhaps the RIGHT OUTER side?)of the diamond is now filled out, and the SQL changes to reflect this:

When executed, our orphans appear in the ChildName column, with NULL against the parent column. Jimmy is nowhere to be seen. I think he just hates kids.

FULL OUTER JOIN - All Parents and all children

Selecting both options from the JOIN property menu gives us a FULL OUTER JOIN:

This returns all records from both sides of the relationship, regardless of whether there are matching records:

CROSS JOIN - Cartesian product

If we remove the JOIN line:

we get a CROSS JOIN, which results, when executed, in the Cartesian product of both tables - 5 parents x 8 children = 40 rows. That means that every row in one table is matched to every row in the other table:

Notice the absence of a JOIN-predicate. There are some obscure uses for CROSS JOINS, including the creation of test data, but generally, they are not used.

Using JOINS to Find Unmatched records

If you study the results of, for example, the LEFT OUTER JOIN, you will notice that Jimmy was returned with a value of NULL in the Children table side of the resultset. Applying this as a filter to a JOIN query is very useful to finding records in one table that have no related records in the second table.

If we type "IS NULL" in the Filter column against the AdultID column of the Children table to the LEFT OUTER JOIN example, we end up with the following diagram and SQL:

and executing this results in Jimmy being returned on his own as the only record in the Parents table that doesn't have a matching record in the Children table:

Conversely, doing the same thing to the AdultID in the Adults table in the RIGHT OUTER JOIN example:

leads to this SQL and diagram:

which when executed results in both Orphans being returned, because again, they have no matching record in the Parents table:

From the questions posted to newsgroups and forums, it seems to me that plenty of people are either unaware of the existence of the Query Designer, or don't use it because they consider it some kind of cheating. For the former group, hopefully this article will show you something new. For the latter group, there is nothing wrong with using the tools available to you. It speeds up development and reduces your chance of errors.

You might also like...

Date Posted:
Last Updated:
Posted by:
Total Views to date: 68158

8 Comments

- Yohan

great article, simple, concise, and yet powerful.

- Mahendran

simple superb article. thanxs

- Amit Ranjan

Simply Superb, well i am a follower of mikesdotnetting since a year...it provides essential things in a quite handy way...
best part is its language simple and easy to understand, no need to repeat...
You rock's...

infinity/10

- Goku Da Master

good article and easy to follow.

- The Zohan

Good stuff, very clear indeed.

- Hugh

Aha! I'm sitting here at 5 in the morning meddling with SQL!

Your article on Inner & Outer Joins has lifted a great fog of confusion. Many thanks for taking the time to write it.
Hugh

- Nashan

Very handy and simple article.Thanks for well explanation

- korim

It's very good tutorial

Recent Comments

dave 20/08/2016 14:57
In response to ASP.NET Web Pages vNext or Razor Pages
Do SimplemembershipProvider in viewpages is supported?...

Steven 18/08/2016 04:40
In response to Entity Framework Code First and Stored Procedures
Can you provide the directives (using statements) you're using for EF7 example?...

yousaid 17/08/2016 22:08
In response to ASP.NET Web Pages vNext or Razor Pages
Increasingly, learning a Microsoft tool is no longer worth the return on investment. Too many tools...

jared 12/08/2016 05:54
In response to ASP.NET Web Pages vNext or Razor Pages
hi mike, just for clarification, is viewpages something different from webpages? is webpages still...

Jocke 08/08/2016 20:37
In response to Loading ASP.NET Core MVC Views From A Database Or Other Location
Good post! If this was to be implemented in a CMS where users can change the view files, how would I...

cyrus 05/08/2016 19:49
In response to ASP.NET Web Pages vNext or Razor Pages
I think adding these features to webpages make it complicated. msft forget webpages goal so we move...

Curt Smith 27/07/2016 20:38
In response to ASP.NET Web Pages vNext or Razor Pages
I am only slightly disappointed to hear that WebMatrix is officially dead, because I suspected this...

Darshan Raj L G 27/07/2016 13:20
In response to Implementing SQL Server Full-Text Search In An ASP.NET MVC Web Application With Entity Framework
I though it would be more helpful for somebody who wants to work with Entity Framework... please EF...

Satyabrata 25/07/2016 08:09
In response to Loading ASP.NET Core MVC Views From A Database Or Other Location
Very Interesting!!...

Jerrie Pelser 23/07/2016 05:08
In response to Loading ASP.NET Core MVC Views From A Database Or Other Location
Very cool concept Mike!...