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

Chapter 3: The Foundation Statements of T-SQL
The WHERE Clause
48
Well, things are starting to get boring again, aren’t they? So let’s add in the WHERE clause. The WHERE clause
allows you to place conditions on what is returned to you. What we have seen thus far is unrestricted
information, in the sense that every row in the table specified has been included in our results. Unrestricted
queries such as these are very useful for populating things like list boxes and combo boxes, and
in other scenarios where you are trying to provide a domain listing.
For our purposes, don’t confuse a domain with that of a Windows domain. A domain
listing is an exclusive list of choices. For example, if you want someone to provide you
with information about a state in the U.S., you might provide them with a list that
limits the domain of choices to just the 50 states. That way, you can be sure that the
option selected will be a valid one. We will see this concept of domains further when
we begin talking about database design, as well as entity versus domain constraints.
Now we want to try looking for more specific information. We don’t want a listing of product names. We
want information on a specific product. Try this: See if you can come up with a query that returns the name,
product number, and reorder point for a product with the ProductID 356.
Let’s break it down and build the query one piece at a time. First, we’re asking for information to be
returned, so we know that we’re looking at a SELECT statement. Our statement of what we want indicates
that we would like the product name, product number, and reorder point, so we’re going to have
to know what the column names are for these pieces of information. We’re also going to need to know
from which table or tables we can retrieve these columns.
Now we’ll take a look at the tables that are available. Since we’ve already used the Production.Product
table once before, we know that it’s there. The Production.Product table has several columns. To give us
a quick listing of our column options we can study the Object Explorer tree of the Production.Product
table from Management Studio. To open this screen in the Management Studio, click Tables underneath
the AdventureWorks2008 database, then expand the Production.Product and Columns nodes. As in
Figure 3-2, you will see each of the columns along with its data type and nullability options. Again, we’ll
see some other methods of finding this information a little later in the chapter.
We don’t have a column called product name, but we do have one that’s probably what we’re looking
for: Name. (Original eh?) The other two columns are, save for the missing space between the two words,
just as easy to identify.
Therefore, our Products table is going to be the place we get our information FROM, and the Name,
ProductNumber, and ReorderPoint columns will be the specific columns from which we’ll get our
information:
SELECT Name, ProductNumber, ReorderPoint
FROM Production.Product
This query, however, still won’t give us the results that we’re after; it will still return too much information.
Run it and you’ll see that it still returns every record in the table rather than just the one we want.
If the table has only a few records and all we want to do is take a quick look at it, this might be fine. After
all, we can look through a small list ourselves, right? But that’s a pretty big if. In any significant system,