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 is probably a better.

That way, you can modify the query (for optimization) at a later date without having to change the code.

Answer 2

Unless you fit the profile in the 2nd paragraph, I'd recommend staying away from views. They're deceptively enticing as a good way to abstract out underlying functionality. But the problem is that once developers start creating views, they tend to start creating different views for every possible combination of tables and fields, and it ends up an uncoordinated explosive mess. The DBA then has to maintain all of them because there's no way of telling which ones are actually used and which ones aren't, and developers end up just writing their own joins anyway because it's easier than wading through and figuring out which existing view to use.

IMO, the only good reason to use views (and a fairly common one) is if the DBA needs to have freedom to modify the underlying tables without breaking existing client code. This is obviously only possible if that logic is on the DB side in a view or proc. If that applies to you, go ahead and use a view. Otherwise, I'd recommend a different way of looking at things.

The power of a view is the abstraction it creates. But the fact is, the abstraction is used only by the client, not by the DB itself. Therefore I find it's better to put that abstraction on the client side. So rather than a view, just define a macro or string generator somewhere in the client code that will create your select statement for you. You can make these simple at first and progressively more intricate as your app progresses. That way you keep the abstration and reusability a view would offer, but avoid the explosion of views and the developer-DBA communication bottlenecks.

Answer 3

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.