Re: Deadly sins againts database performance/scalability

jeff_at_work.com (Jeff) wrote in message news:<bqfgqd$oss$1_at_cronkite.cc.uga.edu>...
> In article <2687bb95.0311301105.6a405a35_at_posting.google.com>, Mark.Powell_at_eds.com (Mark D Powell) wrote:
> >developers need to allow/account for these situations. Rather than
> >say do this or do not do that the guidelines should lay out the side
> >effects of design decisions based on how Oracle handles the work.
> >Then it is up to the developers who should know the data better than
> >the DBA to make the right choices.
> >
> >IMHO -- Mark D Powell --
>
> Bravo. Don't treat developers like dumb-asses unless you want them to be
> dumb-asses.

So what do you do if they are dumb-asses before they've been treated? :-)

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 learned it somewhere else is the way it should be done, and attempting to lay out guidelines as Mark suggests is just flamebait for them. Billy V's Big Lead Pipe Treatment becomes unavoidable. The Dilbertian side effect is management decides that some overly-restrictive rules should be placed on everyone.

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.

Also, I would expect DBA's to be more familiar with global data issues than developers, in a large environment.

jg

--
@home.com is bogus.
http://www.signonsandiego.com/news/uniontrib/mon/business/news_mz1b1im.html