Microsoft SQL Server allows you to add an index to a view, but why would you want to do this?
My understanding is that a view is really just a subquery, i.e., if I say SELECT * FROM myView, i'm really saying SELECT * FROM (myView's Query)
It seems like the indexes on the underlying tables would be the ones that matter the most. So why would you want a separate index on the view?
If the view is indexed then any queries that can be answered using the index only will never need to refer to the underlying tables. This can lead to an enormous improvement in performance.
Essentially, the database engine is maintaining a "solved" version of the query (or, rather, the index of the query) as you update the underlying tables, then using that solved version rather than the original tables when possible.
Here is a good article in Database Journal.
Microsoft SQL Server allows you to add an index to a view, but why would you want to do this?
To speed up the queries.
My understanding is that a view is really just a subquery, i.e., if I say SELECT * FROM myView, i'm really saying SELECT * FROM (myView's Query)
Not always.
By creating a clustered index on a view, you materialize the view, and updates to the underlying tables physically update the view. The queries against this view may or may not access the underlying tables.
Not all views can be indexed.
For instance, if you are using GROUP BY in a view, for it to be indexable it should contain a COUNT_BIG and all aggregate functions in it should distribute over UNION ALL (only SUM and COUNT_BIG actually are). This is required for the index to be maintainable and the update to the underlying tables could update the view in a timely fashion.
the following link provides better worded information than i can say especially in the section under performance increases. Hope it helps
http://technet.microsoft.com/en-us/library/cc917715.aspx
You create an index on a view for the same reason as on a base table: to improve the performance of queries against that view. Another reason for doing it is to implement some uniqueness constraint you can't implement against base tables. SQL Server unfortunately doesn't allow constraints to be created on views.
Related
Is it possible to add indices to a View in Teradata? Aiming to make querying of Views faster by adding indices.
Tried using SQL to check for indexes on existing Views by using SELECT * FROM DBC.Indices. Yet there are only results for Tables, none for Views.
I have also been checked internet, but have so far been unable to find anything so far for Teradata.
I would have expected to be able to find an index on some of the existing Views, if it was possible.
An index is always associated with a table (or with multiple tables in case of the Join index), never with a view.
But: the execution plan of a query (and consequently its performance) depends, among other things, on the indices defined on the tables involved in the query.
So while you can't create an index on a view, you can create indices on the underlying tables, and it will change how the queries referring the view are executed.
However, before starting to create additional indices in the hope of fixing your performance problem, you should first inspect the execution plan of the problematic queries and determine what the correct plan ought to look like. The problem might not be the lack of indices, but rather lack of up-to-date statistics, poor queries, or bad table design (e.g. wrong PI or poor partitioning).
what will happen when I query a view in sql 2000?
Does it query the underlying table? Is making a view on table fasten the query execution?
There is a table with 10 million records(Records from 2005 to till date).
The users are often interested in the current year data.So if i create a view on the table,only using the current year data then would that increase the query performance,while querying the view ?
I mean instead of querying the table with where condition year='2013' , the user can query the view and get better performance?
As Damien stated in his comment, the definitions of views are expanded and the query used to build them is "inlined" into your own query, so it is unlikely that you will get any performance increase by using a standard view.
An alternative is to create an indexed view, which is a standard view that has a clustered index created on it, effectively materialising it and making it act as if it were a table. In non-enterprise editions of SQL server you need to use the NOEXPAND hint when referencing the indexed view to make the optimiser take the index into account, but you can get performance gains this way.
There are special considerations for indexed views, certain settings and conditions that must be set for them to work, it's all detailed here:
Creating an Indexed View
I'm wondering if this is a bad practice or if in general this is the correct approach.
Lets say that I've created a view that combines a few attributes from a few tables.
My question, what do I need to do so I can query against this view as if it were a table without worrying about performance?
All attributes in the original tables are indexed, my concern is that the result view will have hundreds of thousands of records, which I will want to narrow down quite a bit based on user input.
What I'd like to avoid, is having multiple versions of the code that generates this view floating around with a few extra "where" conditions to facilitate the user input filtering.
For example, assume my view has this header VIEW(Name, Type, DateEntered) this may have 100,000+ rows (possibly millions). I'd like to be able to make this view in SQL Server, and then in my application write querlies like this:
SELECT Name, Type, DateEntered FROM MyView WHERE DateEntered BETWEEN #date1 and #date2;
Basically, I am denormalizing my data for a series of reports that need to be run, and I'd like to centralize where I pull the data from, maybe I'm not looking at this problem from the right angle though, so I'm open to alternative ways to attack this.
My question, what do I need to do so I can query against this view as if it were a table without worrying about performance?
SQL Server is very good in view unnesting.
Your queries will be as efficient as if the view's query were used in the query itself.
This means that
CREATE VIEW myview AS
SELECT *
FROM /* complex joins */
SELECT *
FROM mytable
JOIN myiew
ON …
and
SELECT *
FROM mytable
JOIN (
SELECT *
FROM /* complex joins */
) myview
ON …
will have the same performance.
SQL Server 2005 has indexed views - these provide indexes on views. That should help with performance. If the underlying tables already have good indexes on the queried fields, these will be used - you should only add indexed views when this is not the case.
These are known in other database systems as materialized views.
The view will make use of the index in your WHERE clause to filter the results.
Views aren't stored result sets. They're stored queries, so you'll have the performance gained from your indexes each time you query the view.
Why would it perform badly? I, mean you can think of a view as a compiled select statement. It makes use of existing indexes on the underlying tables, even when you add extra where clauses. In my opinion it is a good approach. In any case it's better than having virtually the same select statement scattered all over your application (from a design and maintainability point of view at least).
If not indexed then...
When you query a view, it's ignored. The view is expanded into the main query.
It is the same as querying the main tables directly.
What will kill you is view on top of view on top of view, in my experience.
It should, in general, perform no worse than the inline code.
Note that it is possible to make views which hide very complex processing (joins, pivots, stacked CTEs, etc), and you may never want anyone to be able to SELECT * FROM view on such a view for all time or all products or whatever. If you have standard filter criteria, you can use an inline table-valued function (effectively a parameterized view), which would require all users to supply the expected parameters.
In your case, for instance, they would always have to do:
SELECT Name, Type, DateEntered
FROM MyITVF(#date1, #date2);
To share the view logic between multiple ITVFs, you can build many inline table-valued functions on top of the view, but not give access to the underlying tables or views to users.
the mysql certification guide suggests that views can be used for:
creating a summary that may involve calculations
selecting a set of rows with a WHERE clause, hide irrelevant information
result of a join or union
allow for changes made to base table via a view that preserve the schema of original table to accommodate other applications
but from how to implement search for 2 different table data?
And maybe you're right that it doesn't
work since mysql views are not good
friends with indexing. But still. Is
there anything to search for in the
shops table?
i learn that views dont work well with indexing so, will it be a big performance hit, for the convenience it may provide?
A view can be simply thought of as a SQL query stored permanently on the server. Whatever indices the query optimizes to will be used. In that sense, there is no difference between the SQL query or a view. It does not affect performance any more negatively than the actual SQL query. If anything, since it is stored on the server, and does not need to be evaluated at run time, it is actually faster.
It does afford you these additional advantages
reusability
a single source for optimization
This mysql-forum-thread about indexing views gives a lot of insight into what mysql views actually are.
Some key points:
A view is really nothing more than a stored select statement
The data of a view is the data of tables referenced by the View.
creating an index on a view will not work as of the current version
If merge algorithm is used, then indexes of underlying tables will be used.
The underlying indices are not visible, however. DESCRIBE on a view will show no indexed columns.
MySQL views, according to the official MySQL documentation, are stored queries that when invoked produce a result set.
A database view is nothing but a virtual table or logical table (commonly consist of SELECT query with joins). Because a database view is similar to a database table, which consists of rows and columns, so you can query data against it.
Views should be used when:
Simplifying complex queries (like IF ELSE and JOIN or working with triggers and such)
Putting extra layer of security and limit or restrict data access (since views are merely virtual tables, can be set to be read-only to specific set of DB users and restrict INSERT )
Backward compatibility and query reusability
Working with computed columns. Computed columns should NOT be on DB tables, because the DB schema would be a bad design.
Views should not be use when:
associate table(s) is/are tentative or subjected to frequent structure change.
According to http://www.mysqltutorial.org/introduction-sql-views.aspx
A database table should not have calculated columns however a database view should.
I tend to use a view when I need to calculate totals, counts etc.
Hope that help!
One more down side of view that doesn't work well with mysql replicator as well as it is causing the master a bit behind of the slave.
http://bugs.mysql.com/bug.php?id=30998
I'm using a view ("UsersActive") against my table ("Users"). The view has only one filter, it checks if DateTime Users.DeletedOn is NULL; it basically contains all Users that are not deleted.
If I now execute Linq queries against the view instead of the table, will they still use the table indexes or do I need to create special indexes for the view? In my understanding the View is nothing else but a predefined query and should work just as if I was querying this directly:
SELECT * FROM Users WHERE DeletedON = NULL
Is my assumption that the underlying table's indexes will still be used correct?
Most of the time, SQL Server Query Optimizer is smart enough to use the indexes on the base table. You can see this by looking at the query plans.
If you have enterprise edition of the SQL Server you can also use indexed views.
Views are pretty totally transparent straight to the underlying SQL statements. It's a good reliable design assumption.
An indexed view is very different from a non-indexed view.
A view can effectively be expanded inline by the engine, so any table indexes which are determined by the optimizer can be used.
An indexed view materializes (and keeps up to date) an index. This is available to users of the view, but still might not be used.
An additional note based on your example - an index might not be as effectively used on NULL criteria as it can be on flag or code columns.
Most likely you need to rewrite your query:
SELECT * FROM Users WHERE DeletedON IS NULL
DeletedON = NULL will not be true even if DeletedON IS NULL
The view if not indexed will be regenerated everytime using the query that defines it. If the table in that query is indexed, the table's indexes will be used.
You can also index your view, in which case the dataset will be committed to physical disk and you'll have two sets of indexes.