Re: Oracle is a bigger version of MS Access?

Noons wrote:

> "Billy Verreynne" <vslabs_at_onwe.co.za> wrote in message news:1a75df45.0310020430.6339ced4_at_posting.google.com...
> >
> > > But it's an uphill battle precisely because it's religious (pure belief
> > > without, or deliberately ignoring, any visible means of support).
> >
> > Exactly. Which is why I'm trolling for comments and opinions, backed
> > up personal experience, to also present at the next meeting.
>
> HTML DB might be a way of addressing the "concerns" of the Access crowd?
>

BTW: HTML DB looks like it has it's roots in a Tom Kyte project back in the late 90's (anyone from inside remember Aria?). Based on the 10G demos it has: several years worth of stability; Tom's personal touch going a way back; a very friendly face lift; and (not based in deep study) decent integration with post-8i technology.

>
> > One of the problems I face is the perception that I'm an Oracle
> > fanatic saying that as much as possible must be done in the database.
> > It's difficult to change this perception and show that it is a common
> > and the best practise method - and nothing to do with Oracle
> > "fanatacism".
> >
> > So, how do you counter the opinion that Oracle should be a bit bucket
> > without sounding like a fanatic?
>
> Hmmm, I tend to approach it from a different angle:
>
> Why is it that DATABASE MANAGEMENT systems were created in the first
> place, nearly 35 years ago?
>
> Because EDP (old name for IT) realized LONG AGO that dumping bits
> in a bucket is one of the most inefficient and unsafe ways that is possible
> to imagine of storing data and its relationships. And a virtual
> insurance certificate that along the way someone WILL store the wrong
> information and relations.
>
> Bits in a bucket is also a failsafe way of ensuring that as soon as
> the person who wrote the program is gone and the next maintainer
> comes along, the elaborate application logic that maintains data
> validity at the application level WILL fail and/or BE subverted.
>
> Resulting in what is in effect invalid and incorrect data.
> Which can only result in incorrect and invalid reporting and
> data analysis. With OBVIOUS and tremendous cost to the business.
>
> Data Processing realized all this all those years ago. Hence
> why data integrity rules and data processing rules were moved
> to where they MUST be to ensure that NO ONE errant program can
> subvert them, intentionally or through sheer ignorance: right next
> to the data and in such a way that they cannot be bypassed by ANY
> program logic.
>
> Hence the creation of database systems, which provided the ability
> to maintain not only the integrity of the data against erring programs
> but also of ensuring that no two programs will interpret same data
> relationships and validations in two separate ways.
>
> Show me a programmer or a designer that can guarantee full multiple
> program validity and correctness now and into the future and I'll show
> you a pretentious git with delusions of grandeur.
>
> This is why database systems were created. Because Data Processing
> has BEEN THERE, DONE THAT and suffered deluded gits BEFORE.
> Something modern "design geniuses" would do well to emulate or at
> least learn from...
>
> --
> Cheers
> Nuno Souto
> wizofoz2k_at_yahoo.com.au.nospam

Great approach. As you indicate, this is mainly legit when approaching management & preferrably some management with the old-time scars coming from a background maintaining the in-house stuff.

Careful though when approaching Java-heads. For example, they believe that they recently invented transactions and distributed transaction architecture [the equivalent to XA] as part of the J2EE spec.

The issue is the libraries have grown soooo large that noone has the time to understand the complete library set provided with Java, never mind the stuff external like databases. As a result, the '-heads deal with the external stuff at it's most simplistic level. And that over-simplification causes them to believe they need to invent all this already-stablized stuff. The fact is many of them are young and have not been through the 'been there, done that' cycle. Received on Thu Oct 02 2003 - 14:07:02 CDT