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

Our result set has become a bit smaller:
EmployeeID FirstName LastName
------------- ---------- ----------------
1 Joe Dokey
2 Peter Principle
4 Howard Kilroy
6 Billy Bob
(4 row(s) affected)
A few people are missing versus our first select — just the way we wanted it.
How It Works
As we’ve discussed before, the view really is just a SELECT statement that’s been hidden from the user
so that they can ignore what the SELECT statement says, and instead just consider the results it produces
just as if it were a table — you can liken this to the derived tables we discussed back in Chapter 7.
Because our data was filtered down before we referenced the view by name, our query doesn’t even
need to consider that data (the view has done that for us).
More Complex V iews
Even though I use the term “complex” here — don’t let that scare you. The toughest thing in views is
still, for the most part, simpler than most other things in SQL.
What we’re doing with more complex views is really just adding joins, summarization, and perhaps
some column renaming.
Perhaps one of the most common uses of views is to flatten data — that is, the removal of complexity
that we outlined at the beginning of the chapter. Imagine that we are providing a view for management
to make it easier to check on sales information. No offense to managers who are reading this book, but
managers who write their own complex queries are still a rather rare breed — even in the information age.
For an example, let’s briefly go back to using the AdventureWorks2008 database. Our manager would
like to be able to do simple queries that will tell him or her what orders have been placed for what parts
and which account number was used to place the order. So, we create a view that they can perform very
simple queries on — remember that we are creating this one in AdventureWorks2008:
USE AdventureWorks2008
GO
CREATE VIEW CustomerOrders_vw
AS
SELECT sc.AccountNumber,
Chapter 10: Views
305