Re: Oracle is a bigger version of MS Access?

<ctcgag_at_hotmail.com> wrote in message news:20031004141314.405$OI_at_newsreader.com...
> > 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.

No it most definitely cannot. The whole concept of databases is precisely to avoid data with invalid structure. Which is virtually impossible to maintain programatically if all that is used is bit buckets.
Check out the definition and work of EVERY single true DBMS system since the 60's. Regardless of its internal works.

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

And yet its data wasn't necessarily. And existing data wouldn't have lost its consistency. Which is the point.

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

It can reject relationships that don't make sense. Of course incorrect content data can be entered. It is the function of the program layer to fix that. But incorrectly structured data will not pass. In fact, with some DBMSs you can actually control content as well as structure, but let's not go there.

> And of course the DBMS must itself be programmed with those
> rules which it *is* capable of enforcing.

Of course. I'm assuming a DBMS. Not a bit bucket pretender with a "DBMS" tag attached.

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

And who says it's being assumed? Of course it has to be tested for validity. But once it is tested, there is NO NEED to verify it again for EVERY single accessor. Because it has nothing to do with them and cannot be subverted by them. Something you simply cannot ensure with any programming paradigm for accessors.

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

Of course. So what?

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

No it doesn't. In a DBMS there is no need to maintain data structure validity at every step of the way. Write and test the schema rules ONCE and be done with it. Which is not the case with the Java crowd: they are constantly re-inventing boiled water and duplicating programming efforts.

Writing a virtual class is *not the same* as writing the code that does the actual work. And is NO INSURANCE WHATSOEVER the final code that really deals with data will be correct. No matter how much rubbish OO designers might want to pass as "design".

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

Basic design techniques that have been worked out for ages would be a start, rather than forcing this industry to re-invent the obvious at every single step of every single project.

Some examples:

Having "Java architects" actually aware that single-threaded connections are not scalable would also help. As well as being aware of the capabilities of the software they are using. Such as that databases have worked out ages ago how to efficiently cache data and its indexes and there is NO NEED to re-invent the whole process in Java. Heaps of others...

-- 
Cheers
Nuno Souto
wizofoz2k_at_yahoo.com.au.nospam