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

you are essentially saying to SQL Server: “Give me all of the rows and columns you get when you run
the statement SELECT CustomerName, Contact, Phone FROM Customers.”
We’ve created something of a pass-through situation — that is, our view hasn’t really changed anything,
but rather just “passed through” a filtered version of the data it was accessing. What’s nice about that is
that we have reduced the complexity for the end user. In this day and age, where we have so many tools
to make life easier for the user, this may not seem like all that big of a deal — but to the user, it is.
Let’s go with another view that illustrates what we can do in terms of hiding sensitive data. For this
example, let’s go back to our Employees table in our Accounting database (we’ll create a special version
of the now familiar Accounting database a little later in the chapter). Take a look at the table layout:
Employees
EmployeeID
FirstName
MiddleInitial
LastName
Title
SSN
Salary
HireDate
TerminationDate
ManagerEmpID
Department
Chapter 10: Views
Be aware that, by default, there is nothing special done for a view. The view runs
just as if it were a query run from the command line — there is no pre-optimization
of any kind. This means that you are adding one more layer of overhead between
the request for data and the data being delivered, and thus, that a view is never
going to run as fast as if you had just run the underlying SELECT statement directly.
That said, views exist for a reason — be it security or simplification for the user —
balance your need against the overhead as would seem to fit your particular situation.
Federal law in the U.S. protects some of this information — we must limit access to a “need to know”
basis. Other columns, however, are free for anyone to see. What if we want to expose the unrestricted
301