Re: Sanity check re. layering of views

At Hotsos, Gudmundur Josepsson did a presentation entitled "Moving
Performance Accountability to the Developer". One of the things he
talked about in the presentation was an experience he had as a
consultant where a decision had been made  to use views to get summary
data from a variety of other applications. At one point, he displayed
a slide that showed the breakdown of just one of these views -- with
at least 4 or 5 layers of complicated views underneath it. (Gummi --
see? I did listen. but you can expand on your experience with layered
views)

the problem with layering views comes in when you try to fix
performance problems -- how do you tune the highest level view? All
you need is one badly tuned query in one of the lower level views and
your performance goes through the floor


On Wed, 16 Mar 2005 07:41:00 -0800 (PST), david wendelken
<davewendelken@xxxxxxxxxxxxx> wrote:
> >Do you think it's reasonable to see five layers of views?
> >My instinct it would be ideal to have at most three layers of views.
> 
> That's not a bad instinct!  I used two views to turn a database where each 
> field in a "logical record from the user's viewpoint" is stored in a separate 
> database record, and in which there are multiple versions of answers for each 
> field (only one of which is "the latest") into a view that showed the 
> "logical record" as if it were a table, and only showed the latest version of 
> each field.   Could have been done in one, with the first view as a query in 
> the from clause, but it was easier to debug in two pieces and to write the 
> code generators to build the views the way I did it.  There were thousands of 
> "logical record types" and a code generator was the only way to do it.
> 
> Not knowing the precise problem to be solved, I can't say "5 is more than you 
> need".  5 might be the number needed to make it maintainable by the team of 
> sql developers that you have. :)
> 
> >I don't think it's reasonable to create any layers of views.  It's cheaper
> >and easier to create a brand new view.  Cheaper in that when the query goes
> >bad, it's easier to debug and manage.  And Easier speaks for itself.
> 
> Actually, I tend to think of the layers of views as subroutines in a program.
> Sometimes it makes more sense to just skip the subroutines and write it all 
> in one big glop, other times it makes sense to separate out specific tasks to 
> be done in subroutines.  It's a matter of balancing speed, complexity, time, 
> and re-useability.
> 
> --
> http://www.freelists.org/webpage/oracle-l
>
--
http://www.freelists.org/webpage/oracle-l

Other related posts: