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

In message <40d57dfb$0$93324$e4fe514c_at_news.xs4all.nl>, mAsterdam <mAsterdam_at_vrijdag.org> writes
>Anthony W. Youngman wrote:
>
>> mAsterdam writes
>>>>> R 'loses the ability to view the data' from within M and that
>>>>> would somehow mean M is *more* expressive?
>>>>> The only way I could make sense out of that is
>>>>> if the (appearant) excess expressions in R could
>>>>> *not* be relevant to a solution.
>>>>>
>>>>> Do you have an indication as to what those excess expressions are?
>>>>
>>>> they tend to be data that were collected and stored in the M
>>>>solution and
>>>> designed out (deemed unimportant to retain) for the R solution.
>>>
>>> Just to get it straight: These 'designed out' data *can*
>>> be represented in R (inferred from the R translation of the M solution),
>>> but they are *not* represented in R because of the different design
>>>process (ispired by the nature of M cq. R)?
>> Yes. Because M has retained metadata (which it can express as data
>>in R).
>> But R may not be able to express that in M because the analyst
>>didn't view the metadata as important.
>
>It is R or it is the analyst who did not view the metadata (and it
>would help if you could narrow it down by being more specific - I think
>there is a lot of metadata that you falsely exclude) as important.
>I would say it's the analyst, maybe - somewhat- inspired
>by the language she uses.

Which is better. For the system to store information by default which can be ignored if it is irrelevant, or for the analyst to be forced to take every possible eventuality into account? After all, EVERYONE is fallible :-)
>
>> And even where R expresses an M-like view of the data, it contains
>>less INFORMATION, because R is unaware that it is expressing metadata.
>
>So now languages should be aware of what they are expressing.
>Why this mixing, IMO unnecessary confusing way of saying things?
>
Maybe because I'm not good at expressing myself clearly? But let's go back to the "list or bag" thing. If both the MV and the relational database contain the *same* data, then the MV version is richer because it has retained any order that was there. If the app wants a bag, it can ignore the order. But if the app wants the original list, not only does the relational version have to store more data, but it has to do more with it - it has to sort it before handing it back to the app. The app needs to know that it's supposed to be a list, and also has to know how to convert the set back to an ordered list.

That's what I'm trying to express - a lot of stuff is implicit in the MV approach, which you can ignore if you want. By explicitly forcing this metadata into data, a relational app needs to "know" a lot more to get the same result.

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