This page has 0 threads | Add post

Finding our blogs useful? Please consider helping us to share more!

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. 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 This is part of our full tutorial online on SQL.Have a look also at our SQL training courses for businesses.

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.

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

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

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

SELECT

tblFilm.*,

tblLanguage.Language,

tblCountry.CountryName,

tblCertificate.Certificate,

tblStudio.StudioName

FROM

tblCertificate

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

WHERE

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:

SELECT

FilmName,

FilmOscarWins,

FilmOscarNominations

FROM

vwSpielbergFilms

ORDER BY

FilmOscarWins DESC

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!

Parts of this blog
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

Some other pages relevant to the above blogs include:

This blog has 0 threads

Add a new post

Book any course as classroom, onsite or online training, or as one-to-one consultancy

Free resources

Paid services

Getting help

Where we are

Where you are

Online

Transparent reviews

Delivery of courses

Nicer to work with

Reliable and established

Our training courses

C#

Excel

Google Sheets

MySQL

Power Apps

Power Automate

Power BI and DAX

Python

Report Builder

SQL

SQL Server

VBA Macros

Other training resources

Blogs

Exercises

YouTube tutorials

YouTube shorts

Test your skills

Consultancy

Courseware

Self-paced courses

Newsletters

Publications

Our training venues

London

Manchester

Across the UK

At your site

Online

Why we are different

Hundreds of published reviews

Small class sizes

Outstanding courseware

Online classroom

(Almost) no cancellations

Wise Owl trainers only

Genuine integrity

Invoices after training

30+ years of Wise Owl

Our top 100 clients

BLOGS BY TOPIC

BLOGS BY AUTHOR

The Pros of using Views in SQL Server

Advantage 1 - you can base views, reports and stored procedures on views

Advantage 2 - View don't need the same access rights as stored procedures

Head office

London

Manchester