Re: OO boffins use Oracle RDBMS as a disk.

Martin,

Many thanks for the reply.

Point taken about the performance/design tradeoff. Your case of getting better results doing aggregations in PRO*C is eminently understandable, but from your mail I believe you agree constraint checking is a core feature of Oracle we are unlikely to improve on. I've seen people attempt to improve on Oracle's internal constraint checking. It wasn't successful.

In addition, dropping server side constraints also means cost based query optimization is effectively dropped too.

I would like to suggest they switch to mainframe/VSAM but don't have the courage. ;-)

Regards

"Martin Haltmayer" <Martin.Haltmayer_at_d2mail.de> wrote in message news:3C2621D2.448B115B_at_d2mail.de...
> Hi Space Goat,
>
> I agree with your statements fully.
>
> However, there is a tradeoff between performance and design. In one of our
> projects we had to aggregate quantils of about 100,000,000 rows into some
> 100,000 rows. This was originally done by the analytic functions of
8.1.6.3.0
> (Sun Sparc Solaris 2.6) which parallelized perfectly. This statement took
20
> minutes where the main part of the spent time was reading, aggregating
etc. in a
> 32-processor E10K.
>
> Then we tested to store the 100,000,000 in 100,000 blobs where each blob
> contained 1,000 of the original data and we had Pro*C do the aggregation.
This
> ran 3 minutes.
>
> Against this sixfold speedup there was no argument with design. If we only
had
> to do the aggregation once a day we may have given the performance for the
> design and safety. But because we do this several times a day we chose to
use
> the faster option. I don't like it but I have to acknowledge the facts.
>
> I think Oracle has to improve its software a lot. They should abandon all
the
> buggy and cosmetic features and they should concentrate on their core
business
> which was RDBMS.
>
> Regards,
>
> Martin
>
>
>
> Space Goat wrote:
> >
> > Hi.
> >
> > Up until now my skepticism about the business benefits of OO PROGRAMMING
has
> > allowed me to just sneer from the sidelines.
> > From the outset I'd like to state I'm not totally against OO. It seems
self
> > evident that OO analysis and design are a good thing.
> >
> > I recently poked around in a mission critical application for which it
was
> > said that after couple of hours down time and the company would be dead
in
> > the water.
> >
> > The application is built using 100, 000 lines of C++, some OO/RDBMS
> > persistence software (who's name escapes me) and Oracle 8.1.7.
> >
> > A quick scan of the database revealed that relational integrity
constraints
> > (PRIMARY KEY, FOREIGN KEY, CHECK) were absent without leave. Business
rules
> > constraints were entirely absent.
> >
> > The developers, when confronted with this, said the constraints were
removed
> > following business acceptance testing performance problems. Later this
was
> > retracted by the managers higher up. Managers stated the application was
> > mainly used for batch processing. During process initialization ALL data
is
> > loaded into live memory. After 30 minutes of processing the updates are
> > written back to Oracle. The constraint maintenance functionality of the
> > RDBMS, among others, is entirely delegated to the C++. Hence "Oracle is
> > being used as a disk" (my retort). The application was "designed that
way".
> >
> > Some integrity checking using custom-built scripts is run post batch,
and
> > some is done on a weekly basis.
> >
> > Now, elsewhere in the company the DB design rule in use is that DB
server
> > side constraints are mandatory and client side constraints are optional.
> > However, for the above application this rule was not followed because it
is
> > "mainly used for batch processing".
> >
> > Given the EXTREME mission critical nature of this application I would
say
> > delegating constraint maintenance to custom-built C++ has the following
> > risks:
> >
> > 1. Trusting custom-built software to maintain data integrity is asking
for
> > trouble. In the lifetime of the software it is likely that major bugs
will
> > arise.
> > On the other hand Oracle's constraint mechanism is probably the most
> > tested and reliable software on the planet.
> > 2. There may be human error (DBA) or sabotage. Having server-side
> > constraints may prevent this.
> > 3. Integrity checking post batch is not enough. There may be errors
during
> > the batch run that may take a long time to disentangle.
> >
> > I'd love to know your opinion on this case.
> >
> > Regards
> >
> > Space Goat
> >
> > *** My real email address is space followed by an underscore followed by
the
> > word goat followed by the at sign followed by the word cyberdude
followed
> > by the word .com
> > To anyone who doesn't know why I have done this, my answer is "stay on
the
> > Internet and you will find out.". Deep sigh.
Received on Sun Dec 23 2001 - 12:54:44 CST