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

"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message news:J3gsgSNOmy7AFwBE_at_thewolery.demon.co.uk...
> In message <QBpDc.122156$Sw.52192_at_attbi_s51>, Marshall Spight
> <mspight_at_dnai.com> writes
> >"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message news:1aPaN6Am2x0AFwN3_at_thewolery.demon.co.uk...
> >>
> >> Note that it's easy to go from a list to either of the other two. But in
> >> order to go back, the set or bag needs to contain extra data (ie the
> >> order) over the list.
> >
> >I don't see how you could consider that data "extra" if it was
> >there originally.
> >
> >Anyway, the list [A, B, C] expressed as a set is { (1, A), (2, B), (3, C) }
> >where [] denotes an ordered collection and {} denotes an unordered
> >collection.
>
> Well, you have just created a field called ORDER,

Yes.

> and created the values 1, 2 and 3.

No, they were there already.

> The point is that the data was NOT there initially - it was implicit.

It sounds like what you're saying is that information encoded as order is "not there." This is incorrect; order encodes information.

> If something is implicit, then it quite clearly does not have existence
> in its own right.

Strongly disagree. If it didn't exist, then it couldn't carry any information.

> >Going back to the list from the information-preserving set is not that hard.
>
> Correct. But surely it's better to throw away the implicit ordering if
> it's unnecessary at the point of use, than to suddenly discover that it
> was necessary but that it's been thrown away by accident ... :-)

If you can't tell what information is necessary and what isn't, you're not going to be able to manage that information anyway.

Also, there's no reason why the list [A, B, C] and the set { (1, A), (2, B), (3, C) } can't have the exact same in-memory representation.

Marshall Received on Sat Jul 10 2004 - 03:37:41 CEST