BLOGS BY TOPIC▼
BLOGS BY AUTHOR▼
BLOGS BY YEAR▼
Views are queries that you can save and reuse; but you can also use them as a basis for further queries. They do have their foibles too, as this blog explores.
- Views in SQL Server
- The View Designer
- Scripting views using SQL
- The Pros of using Views in SQL Server (this blog)
- The Disadvantages of Views
Posted by Andy Brown on 17 December 2012
You need a minimum screen resolution of about 700 pixels width to see our blogs. This is because they contain diagrams and tables which would not be viewable easily on a mobile phone or small laptop. Please use a larger tablet, notebook or desktop computer, or change your screen resolution settings.
The Pros of using Views in SQL Server
Should you use views (in particular, as opposed to writing the more powerful stored procedures)? This page will concentrate on the good side of views - we'll consider the disadvantages in the next part of this blog.
If the above sounds like a recommendation to avoid using views, it's anything but - the first advantage trumps all of the disadvantages.
Advantage 1 - you can base views, reports and stored procedures on views
You can base queries on views as well as on tables:
Whether you're writing views in SSMS or creating reports in SSRS, you can always use a view in place of a table.
Suppose that you spend your life working with movies data (perhaps you work for a film company), and you frequently want to work with a subset of the complete dataset (perhaps just the films made by Steven Spielberg). Almost every query that you create will probably:
- Link a few tables together to get the studio, language, country and certificate for each film.
- Apply a filter so that you only see Spielberg films.
To avoid having to keep creating the same SQL, you could create a view, and base all subsequent queries on this view. Here's what the view would look like:
CREATE VIEW vwSpielbergFilms
-- show details for Steven Spielberg films
INNER JOIN tblFilm ON
tblCertificate.CertificateID = tblFilm.FilmCertificateID
INNER JOIN tblCountry ON
tblFilm.FilmCountryID = tblCountry.CountryID
INNER JOIN tblDirector ON
tblFilm.FilmDirectorID = tblDirector.DirectorID
INNER JOIN tblLanguage ON
tblFilm.FilmLanguageID = tblLanguage.LanguageID
INNER JOIN tblStudio ON
tblFilm.FilmStudioID = tblStudio.StudioID
tblDirector.DirectorName = 'Steven Spielberg'
Quite a mouthful!
Apologies for using the * to include all columns from the films table - you might want to be pickier than this, and specify exactly which columns the view should list.
Here's what a query to analyse Spielberg film Oscars would look like:
Here's what this would return:
I think this data predates Schindler's List. Sorry, Steven!
I don't know how many times I've stressed to people on our SQL courses the importance of creating views as above to avoid reinventing wheels for every query that you create.
One thing to stress: the query above will also rerun the vwSpielbergFilms view to get the latest version of the data. If speed is a big issue for you, you'll probably want to consider creating temporary tables of data instead.
Advantage 2 - View don't need the same access rights as stored procedures
Here's some of the things stored procedures can do:
- create and drop tables
- create and drop databases
Your IT department may be deeply reluctant to give you permission to create stored procedures, but they may give you the right to create views (since these can only ever select data).
That ends the case for the defence; time now to look at the case for the prosecution!