Performance ?
-
http://www.sql-server-performance.com/views.asp
Guys this is a kind of news to me. View can degrade the performance? Any comments ?
Who is the Author for this article ?
Kindest Regards,Amit Lohia
-
Most of these tip lists are from Brad Magehee, who is the editor of sql-server-performance.com.
I'm not sure how much of a performance problem there is, and given their benefits for many developers, I think I'd still recommend them.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com -
I agree with you steve. If you retrive all the columns from base tables whether you are using SP or Views there will be impact on performance, It is nothing to do with views.
anyone on the other side of the fence ?
Kindest Regards,Amit Lohia
-
Yep... I've found that lots of folks create monster views with too many columns and really poorly formed SQL with aggragates out the wazoo so its "reusable" code and solves every problem you could ever come up with. In most cases (not all), if you do a SELECT TOP 10 from a view and it takes more than a second, the code of the view should really be examined for performance problems.
I've also found that folks will make a view-of-a-view or join views within other views and the performance will, many times, turn out to be absolutely terrible mostly because of the other problems I sighted.
Lastly, a view is the result of a single outer select... most people just try to do too much inside a single select and it kills performance.
Now that I've said all those negative things about them, correctly formed views with the right indexes on the underlying tables can be a great tool. Incredible speeds can also be achieved through the proper use of indexed views.
Lots of developers use Views as a panacea for supposedly reusable code... views are not a panacea and should be developed eve more carefully than sprocs and udfs.
But that's just my side of the fence
--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)
Intro to Tally Tables and Functions -
Jeff
If we over do anything. It will create a problem but in general I do not think View have that bad of performance that we should avoid.
Amit
Kindest Regards,Amit Lohia
-
Hi, this is Brad, and I wrote this tip. My problem with views is how they are abused by many developers, especially novice developers. Like any tool in SQL Server, it can be used well and not so well. I recommend avoiding views because I have found it is easier to write better, and more efficient code if you stick soley with stored procedures. Just my personal opinion.
Brad M. McGehee
Microsoft SQL Server MVP
Brad M. McGehee
DBA -
I believe I said that...
"Now that I've said all those negative things about them, correctly formed views with the right indexes on the underlying tables can be a great tool. Incredible speeds can also be achieved through the proper use of indexed views."
--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)
Intro to Tally Tables and Functions -
I'm with Jeff ..views and performance = oxymoron
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply