Re: relations aren't types?
Date: Sun, 28 Dec 2003 04:28:14 -0500
"John Jacob" <jingleheimerschmitt_at_hotmail.com> wrote in message
> > From the perspective of a relation, its relation valued attributes are
> > opaque. Those attributes have operations defined that operate on values
> > the attributes' types--that's all the relational model cares about.
> Even when a relation type is used to define an attribute of another
> relation type, it is still not a scalar type. When you say opaque, I
> assume you mean scalar. If you do not, then we need some
> clarification of terms.
Define a scalar type. The relation value in the attribute for each tuple is a single value with defined operations. How does that differ from an integer?
> > > As an example of a unary relation variable over a "non-atomic" type,
> > > consider TimeOfDay.
> > TimeOfDay is just as atomic as any other type. It has values and
> TimeOfDay is not a type, as I said it is a relation variable with a
> relation type having a single attribute of type Time.
> > There is a difference between defining generic operations and defining
> > attributes with generic types. The only attribute mentioned in your
> > has a type of DateTime, which is quite specific. You have described a
> > generic operation that operates on any generic relvar with a LastUpdated
> > attribute. You have not provided an argument favouring any attribute
> > generic type.
> Agreed. Would you object to a relation with an attribute of type
I cannot remember: Is alpha the type with an empty set of values and the
entire universe of operations? Or is alpha the type with the entire universe
of values and the empty set of operations?
I see no use for relvars with attributes of type alpha or omega, but I have
no particular objections to relations with such attributes.
I see no use for relvars with attributes of type alpha or omega, but I have no particular objections to relations with such attributes.
> > > At least one advantage is brevity. This could certainly be claimed as
> > > an implementation advantage, but it is an important one. Indeed, I
> > > argued above that in order to realize this behavior, both concepts are
> > > necessary. While I do think that allowing implicit conversions of
> > > this type could be extremely useful in a database language, it must
> > > never be done at the expense of a more primitive behavior, and it must
> > > be done extremely carefully to avoid destroying the primary reason for
> > > types in the first place, namely semantic verification.
> > Brevity at the expense of integrity or of clarity is a fool's bargain.
> These proposals certainly do not sacrifice integrity. I fail to see
> how integrity is relevant at all to the discussion. As for clarity,
> what specifically do you see as the disadvantages of the proposals
I once worked on a C++ project where the lead developer adopted a naive String class (in the bad old days before STL) that had a cast operator or constructor that would convert any common type to a string and vice versa--in the name of brevity. In a long block of s += ... statements to build a dynamic SQL command, there was one s =+ ... statement.
s += ...;
s += ...;
s =+ " FROM "; // s == "0" after this statement s += ...;
s += ...;
The code compiled without a warning, and it was not at all clear to the lead developer why it wouldn't give a compile error. Received on Sun Dec 28 2003 - 10:28:14 CET