Re: DB clasical structure violation

So clearly you have some non-relational agenda. what database overceomes all the problems? If ROLAP is bad what is good?

On 25 Jun 2002 06:42:28 -0700, anthony.youngman_at_eca-international.com (Anthony Youngman) wrote:

>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 Wed Jun 26 2002 - 08:24:33 CEST