Re: Deadly sins againts database performance/scalability

[EMAIL PROTECTED] (Jeff) wrote in message news:<[EMAIL PROTECTED]>...
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Joel Garry) wrote:
> 
> >So what do you do if they are dumb-asses before they've been treated? 
> >:-)
> 
> Re-examine your hiring and/or compensation practices.  In other words, avoid 
> hiring dumb-asses in the first place.  ;-)
> 
> 
> >Seriously, some of the worst I've seen are newbies with a chip on
> >their shoulder.  They come at it with the attitude that the way they
> 
> Newbies or wet-behind-the-ears young'uns fresh out of college that just need 
> to shut up and mature a bit?  :-)
> 
> 
> >Personally, I'd rather that developers be encouraged to be creative,
> >with a filtering process that explicates Oracle's issues with
> >attempted solutions (in a practical sense that means Explain Plan and
> >code reviews, as Daniel points out).  This tends to be at odds with
> >classical formal design processes.
> 
> What're  "classical formal design processes?"  Because I think code reviews 
> with an experienced DBA that provides developers with insight in how to do 
> things better should be welcomed... as long as the DBA isn't full of shatt (or 
> himself) and/or an ass about it.  I think experienced developers would, at 
> least.

The problem with code walk-throughs is that by the time they happen it
is offen too late to change the design.  Developers need to involve
the DBA with a design walk-thru before code is written.  In my
experience the majority of the time the DBA does not see the code
until there is a production performance problem.  By then major design
changes and different approaches are "too late".

Just another challenge -- Mark D Powell --