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

In message <40dd54f7$0$48920$e4fe514c_at_news.xs4all.nl>, mAsterdam <mAsterdam_at_vrijdag.org> writes
>Ok, so we have some order preserved in M, even if there is no
>explicit field on which to sort (or explicit next/prior field).
>This does not come free of charge:
>When inserting some new piece into an ordered thing, we must
>take care to put it in the right spot in the order. We must
>be aware of the order of earlier, existing things.
>When processing large amounts of data, we have to take care to
>preserve the order: it might be relevant.
>It might not, but we have no way of telling because it is implicit.
>What to do when merging things?

Let's be practical, not theoretical ... :-)

Under what circumstances would a *database* muck about with the data (any data) and do things like altering the order or value of things?

It only ever changes data when under the control of an application or something like that. And the app knows whether or not to preserve order.

And anyway, let's contrast it with a relational database. The rdbms will have an attribute called "sort order" or similar, and it won't have a clue what to do with it. It's up to the app to update that attribute, so whether you have an MV or an R dbms, it's up to the app to control what happens when the data is changed. It's just that "order" is metadata to an MVdbms, but data to an Rdbms.

So the cost is identical, whichever dbms model you are using. But MV scores because it understands and can take advantage of order, if it's appropriate.

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