Re: Deadly sins againts database performance/scalability

jeff_at_work.com (Jeff) wrote in message news:<bqi4so$29h$1_at_cronkite.cc.uga.edu>...
> In article <91884734.0312011531.262b8eeb_at_posting.google.com>, joel-garry_at_home.com (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 -- Received on Wed Dec 03 2003 - 13:45:03 CST