Re: Oracle is a bigger version of MS Access?

"Noons" <wizofoz2k_at_yahoo.com.au> 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?
>
> > 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.

I think the same can be said for database management systems.

> 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.

My design for an RDBMS-based system was subverted (and perverted) just as soon as I turned it over to someone else.

> 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,

There is no way to do that. A DBMS can reject malformatted data, but it can't reject data which properly formatted and plausible, but simply incorrect. And of course the DBMS must itself be programmed with those rules which it *is* capable of enforcing. It doesn't make much sense to assume the people programming the DBMS itself are somehow infallible, while those writing the accessor objects are fallible.

> 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.

The DBMS can control what data it gives two programs, it can't control how those programs interpret that data.

> 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.

That goes equally for DBMS as it does for Java.

> 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...

I agree with you that the modern design geniouses would do well to learn from the past, but it seems we disagree on what it is they should learn.

Xho

-- 
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service              New Rate! $9.95/Month 50GB