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

❑ Aliases are used in both queries — even though it looks like the outer query shouldn’t need
one — because they are required whenever you explicitly refer to a column from the other
query (inside refers to a column on the outside or vice versa).
The latter point concerning needing aliases is a big area of confusion. The fact is
that sometimes you need them and sometimes you don’t. While I don’t tend to use
them at all in the types of nested subqueries that we looked at in the early part of
this chapter, I alias everything when dealing with correlated subqueries.
The hard-and-fast rule is that you must alias any table (and its related columns) that’s
going to be referred to by the other query. The problem is that this can quickly become
very confusing. The way to be on the safe side is to alias everything — that way you’re
positive of which table in which query you’re getting your information from.
We see that 19,134 row(s) affected only once. That’s because it affected 19,134 rows only one time.
Just by observation, we can guess that this version probably runs faster than the two-query version and,
in reality, it does. Again, we’ll look into this a bit more shortly.
In this particular query, the outer query references only the inner query in the WHERE clause — it could
also have requested data from the inner query to include in the select list.
Normally, it’s up to us whether to use an alias or not, but with correlated subqueries they are often
required. This particular query is a really great one for showing why, because the inner and outer
queries are based on the same table. Since both queries are getting information from each other without
aliasing, how would they know which instance of the table data that you were interested in?
Correlated Subqueries in the SELECT List
Subqueries can also be used to provide a different kind of answer in your selection results. This kind of
situation is often found where the information you’re after is fundamentally different from the rest of the
data in your query (for example, you want an aggregation on one field, but you don’t want all the baggage
from that to affect the other fields returned).
To test this, let’s just run a somewhat modified version of the query we used in the previous section.
What we’re going to say we’re after here is just the account number of the customer and the first date on
which that customer ordered something.
This one creates a somewhat more significant change than is probably apparent at first. We’re now asking
for the customer’s account number, which means that we have to bring the Customer table into play.
In addition, we no longer need to build any kind of condition in — we’re asking for all customers (no
restrictions), and we just want to know when each customer's first order date was.
The query actually winds up being a bit simpler than the last one, and it looks like this:
SELECT sc.AccountNumber,
(SELECT Min(OrderDate)
FROM Sales.SalesOrderHeader soh
WHERE soh.CustomerID = sc.CustomerID)
AS OrderDate
FROM Sales.Customer sc;
Chapter 7: Adding More to Our Queries
195