The finaly question becomes what is worse for perforamnce,
is simple -- "doing things to protect programmers, who are paid to write code
for money and do it right, is the worst thing you can do for performance"
In my world -- views are implemented for single use things. When I build a
view, it is for an application. I tend to not use a generic view for
everything. I create a view much like people create subroutines -- for a
So, i will pick neither of 1 or 2 from your first list -- i think they are both
there are no quanitative numbers one can throw on your questions. There are too
many variables. For example, would the exclusion of some columns allow us to
skip some table access by rowid steps? if so, big difference, if not, small
difference. thats just one case. does the inclusion of some columns cause us
to exceed sort areas and swap to disk? and so on.
To me, the right way is "you create a view for a purpose". You NEVER "protect"
programmers, they are supposed to be professionals, not children in need of
Reviewer: Guy from Manchester, England
I agree with Tom, programmers don't need protection and should be able to read a
data / schema design entity diagram to do their job, esp. if there Oracle
However, if you do have inexperienced (in oracle) client side programmers on
your project, then I found that rather that developing a generic "meta layer" of
views to try to cover all potential queries, I would design (or oversee the
design and development) of PLSQL helper packages for the main functions / table
/ entities, including functions that return cursor refs, add, update and delete
functions. This also prevents the programmers using CURSOR FOR loops and SELECT
SYSTIME FROM DUAL with abandon!
This gives client side programmers the tools do their jobs (create click buttons
and forms and stuff) with you (DBA and/or Oracle PLSQL developer) able to
control the inner workings.
Just my 20/20 vision...
I concurr -- i think we need a triumvirate really
o interface programmers. they love the gui and doing cool things on screen.
o database programmers. they understand how the database works, what
transactions are all about, how to work with data.
and in many cases, the database programmers and dba's can actually be one in the
interface programmers that try to do database stuff are many times in so far
over their head. i see it all of the time. they think "its all about the gui,
the application". They have it backwards (IMHO)
and then look at the tkprof and SEE what the real difference is. many times a
view precludes pushing predicates down (it would change the answer for
example!!!) so it is not even apples and oranges comparision.
A view should be used not so much for ad-hoc sql but to hide complexity in code.
views are not evil, views are good, views do not "kill performance" anymore
then SQL kills performance for all a view is is a stored SQL query!
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/94317/viewspace-794107/，如需转载，请注明出处，否则将追究法律责任。