Re: Deadly sins againts database performance/scalability

jeff_at_work.com (Jeff) wrote in message news:<bqnens$jqt$1_at_cronkite.cc.uga.edu>...
> In article <2687bb95.0312031145.3dc3fb7f_at_posting.google.com>, Mark.Powell_at_eds.com (Mark D Powell) wrote:
>
> >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".
>
> I agree 100% that a DBA should be part of the design team along with
> developers. If they aren't... if DBA's are only brought in at production time
> or after the "design concrete" has set, I'd say that's a management problem,
> not a developer problem. Maybe I'm naive or we've different ideas of what a
> "developer" does.
>
> Aside to Joel: I've never worked in a top-down environment... nor have I a lot
> of experience (none positive, that's for sure) with working with outside
> vendors/consultants. So, I'm rather speaking to permanent shops with
> permanent employees.

The particular environment I was referring to was a very large permanent shop with permanent employees. They had bought an off the shelf package and had a large effort to modify it to their purposes, both with contractors and permanent employees. In fact, there were two large shops, in competition to do the same thing. One shop was using a layered approach, putting all new objects in separate schemata with private synonyms, while the other hacked away. They both were using Oracle tools to reverse-engineer the product, and both were traditional top-down shops, newly coming to Oracle from COBOL, and neither had the type of dba that would be necessary for what we are discussing here. Eventually one shops methodology took over, due to political reasons. Somehow, it all got done, albeit slowly. Which is a lot more than can be said for their DW project.

"Management problem" is an understatement.

jg

--
@home.com is bogus.
http://www.sumeiyu.com/