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, T1.f2, T2.f3 FROM table1 T1 join table2 T2" +
   "on T1.id = T2.id AND T1.dt = T2.dt ..."
....
cmd.CommandText = query;

I could also put the query as a view on my SQL server like this:

 CREATE VIEW V1 AS
   "SELECT T1.f1, ..."

Then I can use the view in a simplified query like this:

 string query = "SELECT f1, f2, f3 FROM V1";
 ....
 cmd.CommandText = query;

I am not sure which way is better. Will be the view be faster then a SQL query? By the way, the query I show here is a simplified one. The actual query SELECT is more complicated one.

Answer 1

I would create a VIEW for several reasons

A) A well constructed view does tend to perform faster than a query, though with query optimization you may not notice much of a difference.

B) It keeps knowledge of the database structure within the database itself - adding a good layer of abstraction (as a side note, consider using a stored procedure rather than an inline query - this also keeps database knowledge within the database itself)

C) If you do need to make a structural change to the database, you can keep the view consistent without needing to rebuild your code.

AMENDMENT I'm going to amend this answer in light of some of the comments so as to clarify some points ...

It is absolutely true that a standard view does not provide any real performance gain over a query. A standard view is materialized at run time which essentially makes it no different than a convenient way to execute a query of the same structure. An index view, however, is materialized immediately and the results are persisted in physical storage. As with any design decision, the use of an indexed view should be carefully considered. There is no free lunch; the penalty you pay for use of indexed views comes in the form of additional storage requirements and overhead associated with maintaining the view when there are any changes to the underlying database. These are best used in instances of commonly used complex joining and aggregation of data from multiple tables and in cases in which data is accessed far more frequently than it is changed.

I also concur with comments regarding structural changes - addition of new columns will not affect the view. If, however, data is moved, normalized, archived, etc it can be a good way to insulate such changes from the application. These situations are RARE and the same results can be attained through the use of stored procedures rather than a view.

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. )