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

Anthony W. Youngman wrote:

>>> 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 :-)

> mAsterdam writes:

> 
> :-)
> 
> Analysts using an RDBMS have to be perfect to get it right, while MV 
> does some of the work for the analyst without him even realising it ...
> 

And it does it right - all of the time?

>>>>> 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?
>>
>> Any other complaints about that? Not from me.
>> I suggest that if MV does not convey all relevant data, MV is not
>> good at expressing itself clearly.

> 
> I thought I was talking about me, not MV :-)
> 

I think you are talking about MV all the time :-)

>>> 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.
>>
>> Why not convey it explicitly, if it is relevant?

Or better: Why not convey all information explicitly?

>>> 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.
>>
>> All data expressible in R is expressible in M.
>> True?

> 
> Yes. But if the *same* *data* is stored in both, then M can (normally) 
> express more. (ie if order is not stored as data, then M can still 
> express it.)

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? Received on Sat Jun 26 2004 - 12:50:34 CEST