Re: relations aren't types?

> Define a scalar type.

Read TTM.

> The relation value in the attribute for each tuple is
> a single value with defined operations. How does that differ from an
> integer?

Types are not atomic, values are.

> Sorry. Time is just as atomic as any other type including relation types.

Again, types are not atomic. Values are. If types are atomic, what is a non-atomic type. If there are no non-atomic types, why call them atomic types? Why not just call them types?

> > Agreed. Would you object to a relation with an attribute of type
> > Alpha?
>
> I see no use for relvars with attributes of type alpha or omega, but I have
> no particular objections to relations with such attributes.

Just because you see no value in it does not mean that it does not have value. If you have no objection to relations with attributes of type Alpha, then how can you have an objection to relations with attributes of more generic types? Note carefully that the Alpha scalar type is all values, but not no operations. An operator can certainly be defined that takes an argument of type Alpha. This alone should be enough to convince you that there could be value in allowing generically-typed attributes.

> Implicit type conversions between tuple-valued types and independent
> attributes? You don't see how that sacrifices integrity and clarity? I can
> only conclude you don't want to look for it.

Integrity is the meaning of the database. In order to say that this proposal sacrifices integrity, you must show that it somehow violates some integrity rule. It is not enough to say it does, or to make vague claims about whether or not I am seeking it. As for clarity, an ill-conceived use of a feature of C++ is hardly enough to justify forsaking a short-hand with as much potential gain as the one being proposed. Received on Tue Dec 30 2003 - 03:44:59 CET