T-SQL is SQL Server’s own brand of ANSI/ISO SQL or Structured Query Language.

T-SQL
is
largely ANSI/ISO compliant, but it also has a number of its own extensions to the
language. You’ll
see more of those in later chapters.
Even though, for backward compatibility, SQL Server has a number of different
syntax choices
that are effectively the same, wherever possible you ought to use the ANSI form.
Where there are
different choices available, I will usually show you all of the choices, but again,
stick with the ANSI/
ISO version wherever possible. This is particularly important for situations where
you think your
backend — or database server — might change at some point. Your ANSI code will more
than likely
run on the new database server; however, code that is only T-SQL defi nitely will
not.

One very common use for the inclusive nature of OUTER JOINs is fi nding unmatched
records in the
exclusive table. What do I mean by that? Let’s look at an example.
I’m going to change that special offer question. This time I want to know the
special offer names
for all the special offers that are not associated with any products. Can you come
up with a query
to perform this based on what you know thus far? Actually, the very last query you
ran has you 90
percent of the way there. Think about it for a minute: an OUTER JOIN returns a NULL
value in the
ProductID column wherever there is no match. What you are looking for is pretty
much the same
result set you received in the previous query, except that you want to fi lter out
any records that do
have a ProductID, and you want only the special offer name. To do this, you simply
change the
SELECT list and add an extra condition to the WHERE clause:
SELECT Description
FROM Sales.SpecialOfferProduct ssop
RIGHT OUTER JOIN Sales.SpecialOffer sso
ON ssop.SpecialOfferID = sso.SpecialOfferID

The fi rst was one of the queries where you explored the INNER JOIN. You discovered
by running the
second query that the fi rst had excluded (by design) some rows. Now I’ll show you
how to identify
the excluded rows by using an OUTER JOIN.
You know from the SELECT COUNT(*) query that the fi rst query is missing thousands
of records
from the BusinessEntity table. (It could conceivably be missing records from the
Employee table,
but you’re not interested in that at the moment.) The implication is that there are
records in the
BusinessEntity table that do not have corresponding Employee records. This makes
sense, of
course, because you know that some of the persons are customers or vendor contacts.
While the
manager’s fi rst question was about all the employee contact information, it would
be very common
to ask just the opposite: “Which persons are not employees?” That question is
answered with the
same result obtained by asking, “Which records exist in Person that don’t have
corresponding
records in the Employee table?” The solution has the same stru