Re: no names allowed, we serve types only

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 where
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?

> 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.

KHD Received on Mon Feb 15 2010 - 07:52:11 CET