Using views instead of tables in stored procedures?

Question

Is it a good practice to query views instead of the raw tables in stored procedures? (even if the view doesnt provide any different data)

I always figured it might be a good idea, because its an extra layer of abstraction and its similar to using properties instead of member variables in class functions.

But now I was looking at the stored procedures created by the ASP.NET Membership Provider and they always query against the tables directly.

I am aware that you cant insert data easily when using views, but if the stored procedure only queries data, should you still use tables directly? If yes, whats the main reason? (performance?)

Answer 1

A view is just a macro that expands into an outer query.

If your view contains several joins, then when you join if to other views you suddenly have a 20 or 30 way JOIN when you actually see 3 JOINs in the SQL of the stored procedure. You'll also find that each query is different: why keep joining the same 20 or 30 tables for every query?

Generally, there is no benefit unless the view is indexed/materialised and the optimiser can use it.

Ideas such as having calculations on a single table masked by a view should be in a computed column: why keep calculating it? For a calculation on multiple tables in a view, it should be indexed.

Using a stored procedure already means no base table access (ownership chaining).

There are good uses of views to avoid direct table access by users, or to mask schema changes, or provide some basic security (eg based on SUSER_SNAME), but not for performance or idealogy

Answer 2

Different database optimizers optimize queries in different ways, so its not an easy answer. But generally adding a layer of abstraction can (not definitely) stop the optimizer from using indexes correctly.

In Sql Server if you have a where clause that contains calls like:

• IS NULL
• LIKE '%something'
• NOT EXISTS

it makes it a non-sargable query, ie a query that does not use indexes - or uses them sub-optimally.

I would guess that using a view will also affect the sarg. I'll go and test this (in Sql Server) - I'll be back in 5 minutes.

EDIT

I guess that the answer is 'it depends' and that you need to turn on your query execution plan to be sure, the following test that I did showed no difference between a querying a simple view based on a table and simply querying the underlying table. But it needs further testing as a complex view could act differently.

Answer 3

I have used views in stored procedures in these two cases:

1 - for complex joins or conditions that are needed in multiple procedures

2 - to substitue for a renamed table. For example I had two tables, called 'member' and 'non_member'. I later decided to combine these into a 'user' table. In order to avoid modifying every proc I had ever written, I created views called 'member' and 'non_member', which used where clauses to filter the 'user' table appropriately. All the procs ran as they used to without changes. I can change them to access the new table directly when I have time.

Answer 4

In SQL Server (at least), my understanding is that Stored Procedures are optimized at compile time, and therefore are more efficient in general than views. I am not certain, but I suspect that by executing an SPRC against a view, you may lose any optimization gained this way.

Further, why? As a previous poster sugessted, you may be executing more joins than you need to if one or more of the views you are including are themselves comprised of numerous joins, and this won't be obvious.

Also, my understanding is that one of the primary reasons for using views is to present table data in a format the user can consume, while protecting table data against inadvertent changes. Since the result set from an SPROC is not subject to INSERTS and UPDATES, this point is moot.

Since a stored procedure by design accepts parameters, does not allow the user to interact with table data directly, and can execute any query logic you might use in a view (plus a whole lot more), it seems to me that (with some exceptions) the main reason one might do this is to make CODING easier, at the potential cost of performance and maintainability (what if someone changes one of the views, without realizing your SPROC depend on it?).

I recommend coding it all into the SPROC, unless there is a compelling reason to do otherwise . . .