Re: MV Keys

In article <1141320627.995968.219210_at_i40g2000cwc.googlegroups.com>, jog_at_cs.nott.ac.uk says...
> Jon Heggland wrote:
> > If you instead say that a "cell" can and must contain exactly one value,
> > *but* that value may very well be a list, or a set, or a relation---then
> > there are no problems (in theory).
>
> Neither of these. I was referring to a case where specifiying an
> attribute-name may map to more than one "cell" as you refer to it. i.e.
> not a one-one functional mapping but a generalised one-many mapping.

I don't really understand. You mean several columns/attributes with the same name?

> > Join is crucial, and depends on equality between "cells". But with
> > multiple values, how do you define equality?
>
> Well this has to be specified to the system as with all equality
> matches. Is 15.0 equal to 15? Is "HELLO" equal to "Hello"? How is a
> date greater or less than another? These subjective equality decisions
> are already being made in numerous domains without significant issue..
>
> In a sense this is no different in nature to something such as a C++
> sort template where one has to specify a comparison function. Here,
> when a type is created one can define how comparisons are made, and I
> don't see a problem there.

As long as the type of a bunch of values is well-defined, there is indeed no problem---indeed, that makes the two alternatives I outlined equivalent. However, if any attribute is a set (or list), you probably want (for convenience) to treat it as a single value of its constituent type when it contains only one value, I.e. "Jon" = { "Jon" }. A language that does this may exhibit undesirable behaviour in other places; I believe SQL has trouble with table literals because of this.

-- 
Jon