Materialized Views

  • One of my query is using 4-5 tables using Inner or Left Outer joins.

    These tables are the main tables of the Db and contains alot of data. Also multiple user & multiple applications are inserting data in these tables as well. So will a materialized view by joining these 4-5 tables will give any performance benefit? Or it will be even more overhead?

    Thanks,

    Usman

  • It depends.

    If you have a lot of selects on certain conditions, then a materialized view based on those conditions can increase performance for those selects.

    On the other hand, materialized views, like any index, do slow down insert/update/delete operations.

    In many cases, the slight slow-down on those is worth the large speed-up on selects, but this requires doing some research and making sure the view is exactly what you need.

    Used correctly, a materialized view can speed up lots of things. Used poorly, they can slow down lots of things.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • I tend to agree with the views expressed above. It can be a useful tool, if you consider the load on your system for Ins/Upd/Del

  • usman.tanveer (7/30/2008)


    One of my query is using 4-5 tables using Inner or Left Outer joins.

    These tables are the main tables of the Db and contains alot of data. Also multiple user & multiple applications are inserting data in these tables as well. So will a materialized view by joining these 4-5 tables will give any performance benefit? Or it will be even more overhead?

    Thanks,

    Usman

    I believe that a materialized view will cause you a world of hurt in this particular case because of all the inserts you say you'll be doing.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden (7/30/2008)


    usman.tanveer (7/30/2008)


    One of my query is using 4-5 tables using Inner or Left Outer joins.

    These tables are the main tables of the Db and contains alot of data. Also multiple user & multiple applications are inserting data in these tables as well. So will a materialized view by joining these 4-5 tables will give any performance benefit? Or it will be even more overhead?

    Thanks,

    Usman

    I believe that a materialized view will cause you a world of hurt in this particular case because of all the inserts you say you'll be doing.

    It depends. It will slow down the inserts, but if those are generally single-table, single-row inserts, the performance hit on that might be negligible. What isn't mentioned is what queries the view will be supporting.

    Even with lots of inserts, you can still have a net gain if you have a lot of complex queries that are called frequently.

    I've even had a net gain in insert speed in one case, because of an indexed view that was used by those inserts (Insert...Select). Slowed down the insert part, but gained even more from the select part. (Supported complex business rules in an upsert situation.) Went from 600 ms to 40 ms on a common transaction in that database.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • Actually, Gus' answer is the best answer... "It depends". This is the kind of thing that you need to test.

    Gus, good point about the net gain on things like Insert/Select. 🙂

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Indexed Views will helps by pre-computing aggregations and store them in the index. Moreover, joining tables can be pre-join and results data can be stored.

    This can speed up your queries by approx. 50-75% in general. :w00t:

    But remember, it always depends! 😉

    Good luck.

  • It is truly not suggestible to use an Indexed View when the tables are highly transactional as you mentioned. But if the priority is reporting then you can use the materialized views with NOLOCK on the Tables.

  • Rather you should keep in mind that you will not be allowed to do any properties that affect the deterministic nature of an indexed view like full-text predicates or references to other views aggregation operations etc..

  • I am going to join in with the "It depends" group. You need to test if a materialized view is going to help or not. There really is no definative answer here.

    Test it, and let us know if it helped or hindered you in this situation.

Viewing 10 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic. Login to reply