Re: Sanity check re. layering of 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

>and the associated issue that instead of trying to tune one query
>against a set of base tables you are 'tuning' multiple sets of sql
>(all the sql that gets issued against the view for whatever purpose)
>in one place. So you tend to fix your problem at the expense of other
>parts of the system that you didn't know used that view.

Versus the associated issue of needing to make the same change in more than one view because requirements changed or the initial way they all were coded was done wrong - and, of course, not knowing which views or queries used that invalid business logic - and the risk of producing the wrong answer quickly vs the right answer slowly.

I know the above posters know this, but others may not!

Query tuning is not the reason business people pay for applications - they pay for them to solve a problem. It's a matter of balancing time, money, and risk.

A "query tuning only" perspective (to the exclusion of other criteria) is just as wrong as a "ease of maintenance only" perspective or a "time to market only" perspective or any other set of blinders. The "Right Answer" here is to find the correct balance point between those and other factors. The original poster did not provide enough info for any of us to make an informed judgment about exactly where that balance point should be. We can only provide input on the issues that should be considered.  

--
http://www.freelists.org/webpage/oracle-l