Use SQL View or SQL Query?

Question

I am working on an application to get data from a MS-SQL server (2005). In the command text, I can pass a sql query like this:

string query = \"SELECT T1.f1,         


        

Answer 1

The View may be faster, because you are requesting a shorter command string, but the difference is going to be inconsequential.

The real difference and value of Views, is that like functions and subroutines, they are reusable.

Answer 2

In general I've found it's best to use views for several reasons:

• Complex queries can get hard to read in code
• You can change the view without recompiling
• Related to that, you can handle changes in the underlying database structure in the view without it touching code as long as the same fields get returned

There are probably more reasons, but at this point I would never write a query directly in code.

You should also look into some kind of ORM (Object Relational Mapper) technology like LINQ to SQL (L2S). It lets you use SQL-like queries in your code but everything is abstracted through objects created in the L2S designer.

(I'm actually moving our current L2S objects to run off of views, actually. It's a bit more complicated because the relationships don't come through as well... but it's allowing me to create one set of objects that run across 2 databases, and keep everything nicely abstracted so I can change the underlying table names to fix up naming conventions. )

Answer 3

Or you could use a stored procedure. Using a stored proc will allow SQL to cache the execution plan. I think the same is true of a view. Your first method (ad-hoc query) will probably be the least efficient.

Answer 4

There is no performance difference (unless the text of the sql query is truly gigantic and incurs a cost on the wire).

Answer 5

To me the advantage of views is that you can apply a security context to them. Or in extreme scenarios you can use distributed partitioned views for performance reasons. Otherwise they complexify versioning. You now have to make sure the correct version of the view is deployed as well as the new build of your data access dll.

I used to argue that stored procs were the way to go because they are a) compiled (faster) and b) a security boundary. In the real world this is often a premature optimization. The SQL command text sent from the client is usually peformant enough (as well as easier to version and deploy) and access control at the table level or even the entire database is adequate in many cases.

Answer 6

Views aren't a performance feature. They exist to reduce the number of joins and to allow you to denormalize without actually denormalizing.

In other words, use whichever makes your code the simplest and don't change for performance reasons unless you have good reason to do so. These kinds of optimizations usually aren't worth it.