Re: DB clasical structure violation

Lee Fesperman <firstsql_at_ix.netcom.com> wrote in message news:<3D17D7CD.230C_at_ix.netcom.com>...
> Anthony W. Youngman wrote:
> >
> >
> > I'll ask you one question - are you jumping to conclusions? ...
> >
> > I would suggest the OP investigate Multi-Value (or Network, or
> > hierarchical, etc - basically something that's NOT an *R*DBMS).
>
> And why would you suggest defective technology that was discarded 20 years ago?
>
Why, then, are Oracle and Microsoft busy copying the features that we've had for thirty years, and adding them to their databases? Are you saying that they're busy adding square wheels?

Why did IBM spend all that money on Informix? It may be rumour, but as far as we can make out the bulk of the "value" that IBM saw in Informix was in the fact that it owned two MultiValue databases.

And lastly, why does all the evidence I know about point to the fact that, for the same amount of data, a multi-value database will do the job quicker, cheaper, and use less hardware. Okay, there are few formal studies, but the conclusion reached was that given two companies of similar size, the MV-based company spent about half as much money as the other to look after its database.

As I see it, the current status of databases can be summed up in one word - "buzzworditis". If it doesn't do SQL it must be old-hat. Never mind that set theory is just that - THEORY! Never mind that other forms of database are provably better in many circumstances.

The MV engine allows you to program as if you had a relational database, or a tree database, or a hierarchical database or whatever. And I would strongly advise that a programmer should know those theories. But SQL carries a massive real-world performance hit (never mind the fact that theory and reality rarely coincide - why force a non-relational real world scenario into a relational straight-jacket?).

But using MV, it is EASY to design a database that (a) does not contain redundant data, (b) enforces a considerable (if not total) degree of referential integrity, (c) is not 3NF, and (4) kicks the hell out of its SQL equivalent on speed, disk space, maintainability, and cost-effectiveness.

The really big problem that MV suffers is that it is simple for users to understand. As a result there are far too many crap systems out there written by users for users. If MS Access is a nightmare for professionals today, so Pick ACCESS was a nightmare maybe 10-15 years ago. But with a pro who can design a database, normalise it, denormalise back into MV, and implement properly, you'll have a good system. And you'll end up with a better system, quicker than with SQL.

Cheers,
Wol Received on Tue Jun 25 2002 - 15:42:28 CEST