Re: In an RDBMS, what does "Data" mean?

In message <40c8a8d5$0$6795$e4fe514c_at_news.xs4all.nl>, mAsterdam <mAsterdam_at_vrijdag.org> writes
>Anthony W. Youngman wrote:
>
>> So if I put my data into an MV database I can access it as if it were
>>in an RDBMS. However, the converse is not true.
>
>It would be very interesting to know - in some detail -
>what kind of data gives difficulties in putting stuff
>from a RDBMS into a MV database.
>This maybe somewhat awkward in this newsgroup, because some
>will be just waiting to say: See? You *can* express proposition_set(x)
>in a RDBMS, and you *can't* in MV, therefore MV is better.
>More is not a priori better.
>
>But I trust you can stand that reaction. Could you give some examples?
>
Actually, all you have to do to make RDBMS appear (superficially) to look like MV is to declare the appropriate views. This does, however, have the unfortunate side-effect of presenting your application with apparently redundant data. The app is also unaware of "if I change this, then that will change too" responses. Or "if I delete that, then the other will go with it".

However, what you can not do with RDBMS is predict system response :-) With MV, you can *prove* that it's damn near impossible to improve on it...

You also have difficulty guessing which tables represent which real-world object - while MV has no guarantees either, your chances of being correct "by accident" are much, much higher. Does an address table represent a company address, a billing address, a shipping address or what? While a relational table may make it clear in the name, MV makes it clear because it would be part of the company file, or the invoice file, or whatever.

I gather it is possible to hide the underlying tables such that an app can access them, but only through views that the dba wishes to permit. With MV, that extra "clutter" isn't there...

Basically, MV is so much simpler :-) the database organisation maps roughly one-to-one to real-world reality :-)

Actually, it's quite difficult to answer your question - we've taken so much from relational :-) But we've taken mostly in "the theory of good design", and not made any changes to the fundamental design of MV, just in how we use it. I think the most important difference is that thing about being able to predict real-world system response. Something relational theory actively avoids... and as I comment elsewhere, the fact that MV stores so much more information as metadata, not data, so it's actually available to the dbms to help it optimise.

Cheers,
Wol

-- 
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999