Hi,
I have a View, which is actually a Union of some joins of some Tables. All
these Tables have indexes.
Will these indexes speed up a query when doing a Select on the View? Or will
the view behave as a non-indexed table? Should I take in account a lack of
performance when using the view?
any answers, explanations, workarounds for this are welcome!
Thanks a lot in advance,
PieterPieter wrote:
> Hi,
> I have a View, which is actually a Union of some joins of some
> Tables. All these Tables have indexes.
> Will these indexes speed up a query when doing a Select on the View?
> Or will the view behave as a non-indexed table? Should I take in
> account a lack of performance when using the view?
Indexes are used if appropriate for your query criteria. You can see this
by looking at the execution plan with QA.
Kind regards
robert|||Hi Pieter
Views are virtual tables and they are not actual tables. When you try to
query a view, u will actually be executing a query.
The query will use the same indexes that a table is using.
However u can create an index on views, creating an index on a view will
effect that query only and not the main table
please let me know if u have any questions
best Regards,
Chandra
http://chanduas.blogspot.com/
http://www.SQLResource.com/
---
"Pieter" wrote:
> Hi,
> I have a View, which is actually a Union of some joins of some Tables. All
> these Tables have indexes.
> Will these indexes speed up a query when doing a Select on the View? Or will
> the view behave as a non-indexed table? Should I take in account a lack of
> performance when using the view?
> any answers, explanations, workarounds for this are welcome!
> Thanks a lot in advance,
> Pieter
>
>|||Pieter,
> Will these indexes speed up a query when doing a Select on the View?
The answer is "it depends". i.e., what columns are you asking for? what
rows? do the index(es) match the row criteria? are the columns highly
selective? etc.. etc...
If the optimizer determines that an index(es) can assist in accessing the
data from the underlying tables when the view is queried, then the optimizer
will likely use the index(es). Use the Display Estimated Execution Plan
(Ctrl+L) to determine the predicted access method.
Creating an index on a view (clustered) will make a copy of the data. This
approach is useful when the underlying data does not change very often and
aggregates are involved.
HTH
Jerry
"Pieter" <pietercoucke@.hotmail.com> wrote in message
news:Olj4WGX2FHA.2436@.TK2MSFTNGP10.phx.gbl...
> Hi,
> I have a View, which is actually a Union of some joins of some Tables. All
> these Tables have indexes.
> Will these indexes speed up a query when doing a Select on the View? Or
> will the view behave as a non-indexed table? Should I take in account a
> lack of performance when using the view?
> any answers, explanations, workarounds for this are welcome!
> Thanks a lot in advance,
> Pieter
>|||Ok thanks a lot for the info!
One more question: In the enterprise Manager the option "All Tasks" ->
"Manage Indexes" is disabled when right-clicking on the View. Is the only
way to manage indexes on a View via the query analyzer?
"Chandra" <chandra@.discussions.microsoft.com> wrote in message
news:EFC3D7B8-44AE-4721-9875-9EFF46F72190@.microsoft.com...
> Hi Pieter
> Views are virtual tables and they are not actual tables. When you try to
> query a view, u will actually be executing a query.
> The query will use the same indexes that a table is using.
> However u can create an index on views, creating an index on a view will
> effect that query only and not the main table
> please let me know if u have any questions
>
> --
> best Regards,
> Chandra
> http://chanduas.blogspot.com/
> http://www.SQLResource.com/
> ---
>
> "Pieter" wrote:
>> Hi,
>> I have a View, which is actually a Union of some joins of some Tables.
>> All
>> these Tables have indexes.
>> Will these indexes speed up a query when doing a Select on the View? Or
>> will
>> the view behave as a non-indexed table? Should I take in account a lack
>> of
>> performance when using the view?
>> any answers, explanations, workarounds for this are welcome!
>> Thanks a lot in advance,
>> Pieter
>>
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment