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

We can figure out which BusinessEntityID is which just by looking at what table we selected first and
matching it with the first BusinessEntityID column that shows up, but this is tedious at best, and at
worst, prone to errors. That’s one of many reasons why using the plain * operator in JOINs is ill-advised.
In the case of an INNER JOIN, however, it’s not really that much of a problem because we know that
both BusinessEntityID columns, even though they came from different tables, will be exact duplicates
of each other. How do we know that? Think about it — since we’re doing an INNER JOIN on those two
columns, they have to match or the record wouldn’t have been returned! Don’t get in the habit of counting
on this, however. When we look at other JOIN types, we’ll find that we can’t depend on the JOIN
values being equal.
As for all columns being returned from both tables, that is as expected. We used the * operator, which as
we’ve learned before is going to return all columns to us. As I mentioned earlier, the use of the * operator
in joins is a bad habit. It’s quick and easy, but it’s also dirty — it is error-prone and can result in poor
performance.
As I indicated back in Chapter 3, one good principle to adopt early on is to select what you need and
need what you select. What I’m getting at here is that every additional record or column that you return
takes up additional network bandwidth and often additional query processing on your SQL Server. The
upshot is that selecting unnecessary information hurts performance not only for the current user, but
also for every other user of the system and for users of the network on which the SQL Server resides.
Select only the columns that you are going to be using and make your WHERE clause as restrictive as
possible.
If you insist on using the * operator, you should use it only for the tables from which you need all the
columns. That’s right — the * operator can be used on a per-table basis. For example, if we wanted all of
the base information for our contact, but only needed the Employee table to figure out their JobTitle,
we could have changed your query to read:
SELECT Person.BusinessEntity.*, JobTitle
FROM Person.BusinessEntity
INNER JOIN HumanResources.Employee
ON Person.BusinessEntity.BusinessEntityID =
HumanResources.Employee.BusinessEntityID
If you scroll over to the right in the results of this query, you’ll see that most of the Employee-related
information is now gone. Indeed, we also only have one instance of the BusinessEntityID column.
What we get in our result set contains all the columns from the BusinessEntity table (since we used
the * qualified for just that table — your one instance of BusinessEntityID came from this part of the
SELECT list) and the only column that had the name JobTitle (which happened to be from the
Employee table). Now let’s try it again, with only one slight change:
SELECT Person.BusinessEntity.*, BusinessEntityID
FROM Person.BusinessEntity
INNER JOIN HumanResources.Employee
ON Person.BusinessEntity.BusinessEntityID =
HumanResources.Employee.BusinessEntityID
Chapter 4: JOINs
85