WiseOwl Training - Established 1992 Wise Owl Training

Established May 1992
30 years in business
Wise Owl Training
30 years in business
See 519 reviews for our classroom and online training
Creating views in T-SQL or in the view designer
Part four of a five-part series of blogs

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.

  1. Views in SQL Server
  2. The View Designer
  3. Scripting views using SQL
  4. The Pros of using Views in SQL Server (this blog)
  5. The Disadvantages of Views

This is part of our full tutorial online on SQL.Have a look also at our SQL training courses for businesses.

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:

Basing views on views

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










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


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:








FilmOscarWins DESC

Here's what this would return:

List of films with Oscars

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!

This blog has 0 threads Add post