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

Chapter 7: Adding More to Our Queries
As you can see, we were able to take a seemingly impossible query and make it both possible and even
reasonably well performing.
Keep in mind that derived tables aren’t the solutions for everything. For example, if the result set is
going to be fairly large and you’re going to have lots of joined records, then you may want to look at
using a temporary table and building an index on it (derived tables have no indexes). Every situation is
different, but now you have one more weapon in your arsenal.
The EXISTS Operator
200
I call EXISTS an operator, but Books Online calls it a keyword. That’s probably because it defies
description in some senses. It’s an operator much like the IN keyword is, but it also looks at things just
a bit differently.
When you use EXISTS, you don’t really return data — instead, you return a simple TRUE/FALSE regarding
the existence of data that meets the criteria established in the query that the EXISTS statement is
operating against.
Let’s go right to an example, so you can see how this gets applied. What we’re going to query here is a
list of persons who are employees:
SELECT BusinessEntityID, LastName + ', ' + FirstName AS Name
FROM Person.Person pp
WHERE EXISTS
(SELECT BusinessEntityID
FROM HumanResources.Employee hre
WHERE hre.BusinessEntityID = pp.BusinessEntityID);
As we might expect, this gets us a relatively small subset of our Person table — 290 of them:
BusinessEntityID Name
---------------- ----------------------------------------------------------
263 Trenary, Jean
78 D'sa, Reuben
242 Poe, Deborah
…
…
95 Scardelis, Jim
215 Harrington, Mark
112 Evans, John
(290 row(s) affected)
We could have easily done this same thing with a join:
SELECT pp.BusinessEntityID, LastName + ', ' + FirstName AS Name
FROM Person.Person pp
JOIN HumanResources.Employee hre
ON pp.BusinessEntityID = hre.BusinessEntityID;