Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

The question you should be asking now is, “Which way is best?” Quite often in SQL, there are several
ways of executing the query without one having any significant advantage over the other — this is not
one of those times.
I would most definitely steer you to the second of the two solutions.
The reason has to do with navigating as quickly as possible to your data. If you keep adding OUTER
JOINs not because of what’s happening with the current table you’re trying to add in, but because you’re
trying to carry through an earlier JOIN result, you are much more likely to include something you don’t
intend, or to make some sort of mistake in your overall logic. The second solution addresses this by
using only the OUTER JOIN where necessary — just once. You can’t always create a situation where the
JOINs can be moved around to this extent, but you often can.
I can’t stress enough how often I see errors with JOIN order. It is one of those areas that just seems to
give developers fits. Time after time I get called in to look over a query that someone has spent hours
verifying each section of, and it seems that at least half the time I get asked whether I know about this
SQL Server “bug.” The bug isn’t in SQL Server — it’s with the developer. If you take anything away
from this section, I hope it is that JOIN order is one of the first places to look for errors when the results
aren’t coming up as you expect.
Seeing Both Sides with FULL JOINs
Chapter 4: JOINs
The rule of thumb is to get all of the INNER JOINs you can out of the way first; you
will then find yourself using the minimum number of OUTER JOINs and decreasing
the number of errors in your data.
Like many things in SQL, a FULL JOIN (also known as a FULL OUTER JOIN) is basically what it sounds
like — it is a matching up of data on both sides of the JOIN with everything included, no matter what
side of the JOIN it is on.
FULL JOINs seem really cool when you learn them and then almost never get used. You’ll find an honest
politician more often than you’ll find a FULL JOIN in use. Their main purpose in life is to look at the
complete relationship between data without giving preference to one side or the other. You want to
know about every record on both sides of the equation — with nothing left out.
A FULL JOIN is perhaps best described as what you would get if you could do a LEFT JOIN and a
RIGHT JOIN in the same JOIN. You get all the records that match, based on the JOIN field(s). You also
get any records that exist only on the left side, with NULLs being returned for columns from the right
side. Finally, you get any records that exist only on the right side, with NULLs being returned for columns
from the left side. Note that, when I say finally, I don’t mean to imply that they’ll be last in the query. The
result order you get will (unless you use an ORDER BY clause) depend entirely on what SQL Server
thinks is the least costly way to retrieve your records.
101