Re: OO boffins use Oracle RDBMS as a disk.

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:26:26 CST