Stored Procedures Vs. Views

Question

I have used both but what I am not clear is when I should prefer one over the other. I mean I know stored procedure can take in parameters...but really we can still perform the same thing using Views too right ?

So considering performance and other aspects when and why should I prefer one over the other ?

Solution 1

Well, I'd use stored proc for encapsulation of code and control permissions better.

A view is not really encapsulation: it's a macro that expands. If you start joining views pretty soon you'll have some horrendous queries. Yes they can be JOINed but they shouldn't..

Saying that, views are a tool that have their place (indexed views for example) like stored procs.

Solution 2

The advantage of views is that they can be treated just like tables. You can use WHERE to get filtered data from them, JOIN into them, et cetera. You can even INSERT data into them if they're simple enough. Views also allow you to index their results, unlike stored procedures.

Solution 3

A View is just like a single saved query statement, it cannot contain complex logic or multiple statements (beyond the use of union etc). For anything complex or customizable via parameters you would choose stored procedures which allow much greater flexibility.

It's common to use a combination of Views and Stored Procedures in a database architecture, and perhaps for very different reasons. Sometimes it's to achieve backward compatibility in sprocs when schema is re-engineered, sometimes to make the data more manipulatable compared with the way it's stored natively in tables (de-normalized views).

Heavy use of Views can degrade performance as it's more difficult for SQL Server to optimize these queries. However it is possible to use indexed-views which can actually enhance performance when working with joins in the same way as indexed-tables. There are much tighter restrictions on the allowed syntax when implementing indexed-views and a lot of subtleties in actually getting them working depending on the edition of SQL Server.

Think of Views as being more like tables than stored procedures.

Solution 4

The main advantage of stored procedures is that they allow you to incorporate logic (scripting). This logic may be as simple as an IF/ELSE or more complex such as DO WHILE loops, SWITCH/CASE.

Solution 5

I correlate the use of stored procedures to the need for sending/receiving transactions to and from the database. That is, whenever I need to send data to my database, I use a stored procedure. The same is true when I want to update data or query the database for information to be used in my application.

Database views are great to use when you want to provide a subset of fields from a given table, allow your MS Access users to view the data without risk of modifying it and to ensure your reports are going to generate the anticpated results.

View more solutions

Comments

[samiretas]

First, you shouldn't have MS Access users. Second, proper security and permissions should prevent them from modifying data. Not views.

[ZygD]

See my answer... ? The mentality is "we can have a view that does all this stuff for us", Then view join view join view = horrible query on base tables. Seen it, fixed it several times before. And answered questions on it too stackoverflow.com/search?q=user%3A27535+macro%2Bview

[ZygD]

Yes, but is a view for encapsulation or for joining? JOINIng alone is not a good enough reason. If you have such simple views so that JOINing is not issue, why not use base tables? Views are abused way too often.

[Evan Carroll]

These arguments against VIEWs seem weak and rely on either broad generalizations or a bad query planner. Look at the opposite side of the coin, the critiques think using a Stored Proc to replace a VIEW is a good idea just because it can't be used in a JOIN.. This seems rather crazy.

[Bennor McCarthy]

@gbn: The problem you are talking about is no fault of views, it's just the unfortunate side-effect of people using the views without understanding the implications. Unfortunately, it seems that I see abuse of views far mor often than correct use of them.

[Freelancer]

This answer was very much imp to me. But i am wondering, how to run views as i know how to run stored proc as exec spName.please guid me.

[ZygD]

@Freelancer: SELECT * FROM View, Just like a table

[Hibou57]

“You can even INSERT data into them if they're simple though”: this may in return gives a rationale for the choice of stored procedure: this prevent insertion attempts (inserting in view may only insert in another table and not add anything in the target view, so inserting in a view, may be something one wish to disallow).