Re: no names allowed, we serve types only
Date: Mon, 15 Feb 2010 10:30:48 -0400
Keith H Duggar wrote:
> On Feb 14, 2:38 pm, r..._at_raampje.lan (Reinier Post) wrote:
>>Keith H Duggar wrote: >> >>>You think my proposal does not allow you to uniquely address header >>>attributes? I think you need to try again, perhaps with less of a >>>focus on "telling us" what sets and ordered pairs are. >> >>Perhaps it would help if you explain what a 'copied type' is
> I was hoping I could get away with just a loose intuitive notion for
> what it is ;-) If X is a typecopy of Y then X and Y are distinct types
> that are mutually coercible and whose extensions are equal. If need be
> we can go into much more detail. However, if possible I'd like to
> focus on what usefulness names add other than to handle attributes
> with the same type?
> For example, just for the sake of argument, pretend we are working
> in a universe where every attribute of a relation always has a unique
> type in that relation. Ie just pretend that there is never a case
> we want to have two or more attributes in the same relation having the
> same type. Now, in this world do we gain anything any usefulness at
> all by having attribute names?
Yes. We gain control over natural join.
>>and how 'copying types' is more convenient than ordering >>or naming different attributes with the same type.
> I don't know whether it necessarily more convenient but I do believe
> it simplifies the relational model. For one, it is often the case that
> one already has unique types and thus can already construct a header
> without the additional "attribute names". Second, requiring unique
> types and reducing the header to a simple set eliminates the need to
> define an additional uniqueness constraint across <name,type> pairs.
But you haven't really done that. Your "copy" declaration must still track the underlying type. Received on Mon Feb 15 2010 - 08:30:48 CST