Are database views only a means to simplify the access of data or does it provide performance benefits when accessing the views as opposed to just running the query which the view is based on? I suspect views are functionally equivalent to just the adding the stored view query to each query on the view data, is this correct or are there other details and/or optimizations happening?
+4
A:
It depends on the RDBMS, but usually there isn't optimization going on, and it's just a convenient way to simplify queries. Some database systems use "materialized views" however, which do use a caching mechanism.
Christian Oudard
2009-02-09 18:28:36
+2
A:
Usually a view is just a way to create a common shorthand for defining result sets that you need frequently.
However, there is a downside. The temptation is to add in every column you think you might need somewhere sometime when you might like to use the view. So YAGNI is violated. Not only columns, but sometimes additional outer joins get tacked on "just in case". So covering indexes might not cover any more, and the query plan may increase in complexity (and drop in efficiency).
YAGNI is a critical concept in SQL design.
le dorfier
2009-02-09 18:33:40
Funny how I always adhered to the YAGNI principles but didn't know they actually existed until I looked up YAGNI :)
SAMills
2009-02-09 18:42:33
+4
A:
I have always considered Views to be like a read-only Stored Procedures. You give the database as much information as you can in advance so it can pre-compile as best it can.
You can index views as well allowing you access to an optimised view of the data you are after for the type of query you are running.
Robin Day
2009-02-09 18:34:24
Any real examples of this ? Do you know any RDMS that will perform quicker on a view than on a equivalent select statement ? Of course index helps, but that index also helps the select statement. Your answer implies that a view is faster, I was just wondering if you have proof or just guessing ?
sindre j
2009-02-09 19:00:39
No DB server I'm aware of creates a query execution plan at the time of view or stored procedure creation. Execution plans require index statistics, which are not available at compile time. The compilation just transforms the SQL/DDL into an internal format.
Craig Stuntz
2009-02-09 19:04:34
sindre, some DB servers support "indexed views," which are more like "materialized views" -- closer to an automatically maintained table than a view per se.
Craig Stuntz
2009-02-09 19:08:15
+1
A:
Generally speaking, views should perform equivalently to a query written directly on the underlying tables.
But: there may be edge cases, and it would behoove you to test your code. All modern RDBMS systems have tools that will let you see the queryplans, and monitor execution. Don't take my (or anybody else's) word for it, when you can have the definitive data at your fingertips.
Michael Dorfman
2009-02-09 18:38:11
+4
A:
Although a certain query running inside a view and the same query running outside of the view should perform equivalently, things get much more complicated quickly when you need to join two views together. You can easily end up bringing tables that you don't need into the query, or bringing tables in redundantly. The database's optimizer may have more trouble creating a good query execution plan. So while views can be very good in terms of allowing more fine grained security and the like, they are not necessarily good for modularity.
Craig Stuntz
2009-02-09 18:51:28