Results 1 to 3 of 3

Thread: View life cycle

  1. #1
    Join Date
    Feb 2011
    Posts
    5

    Unanswered: View life cycle

    As we say views are faster and logical.So suppose I am having one table & on that table I have created one view.Now if I will fire same query on table and view what difference it will have.So I just want to know life cycle of same select query on table & view.

  2. #2
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    Quote Originally Posted by Amit477 View Post
    As we say views are faster and logical.
    faster than what?

    a query against a table and a similar query against a view of the same table will ~not~ have different performance profiles

    performance depends on availability of appropriate indexes, not on whether a view was used
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  3. #3
    Join Date
    Nov 2004
    Posts
    1,427
    Provided Answers: 4
    As we say views are faster and logical.
    Who are the "we" in that sentence?

    A view is a piece of SQL code that you can use without knowing the exact internal code, like a macro. It can shield the complexity of the SQL from those who use it (developers, end users). Perhaps that is what you meant with "logical".

    If you find out that a certain view performs badly, you can fine tune that view. And all the programs that use that view, will suddenly perform a lot better, after you have replaced the underlying SQL of the view with better performing SQL code.
    That is the closest way to get a view perform faster (than letting everyone write their own SQL code).
    Now if I will fire same query on table and view what difference it will have.
    None.
    So I just want to know life cycle of same select query on table & view.
    What do you mean by that?

    What do I consider the main advantages of views:
    - they are a centralised piece of code that can easily be managed and fine tuned, improving all the systems using that view
    - they can shield the complexity of certain business rules, making programming easier
    - they take away the burden (and chances of making mistakes) of having to do repetitive tasks, like only selecting "active" records, performing the JOINS with related tables, ... also making programming easier
    - sometimes they can even shield changes in the database structure, minimising their impact on existing programs
    With kind regards . . . . . SQL Server 2000/2005/2012
    Wim

    Grabel's Law: 2 is not equal to 3 -- not even for very large values of 2.
    Pat Phelan's Law: 2 very definitely CAN equal 3 -- in at least two programming languages

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •