Re: Distributed foreign keys (was Re: Category Types)
Date: Sat, 05 Jul 2003 16:44:37 GMT
Message-ID: <VfDNa.110647$R73.12405_at_sccrnsc04>
"Bob Badour" <bbadour_at_golden.net> wrote in message news:o1pNa.287$_T1.36633719_at_mantis.golden.net...
>
> I am not sure how a database algebra would affect the catalog. Representing
> types, type generators and operations seems like the tricky part to me;
> although, I have a few ideas germinating. Type generators seem particularly
> tricky because they could instantiate a type that changes the known type of
> some value already in the database.
Why would they? Why should something change its type just because it can? TTM seems to assume this, but never presents a decent argument for it. This is related to their "most specific type unique" rule, but that always struck me as just being there to make implementation of SbyC easier.
So value X could belong to either of two possible subtypes; what's the problem? If we buy that function *semantics* (as opposed to implementation) for subtypes is the same, then it doesn't matter.
Put another way, why couldn't I have the following types:
T1 = {a, b, c} // a, b, c are values
T2 <: T1 = {a, b}
T3 <: T1 = {b, c}
( The <: operator means "is a subtype of.")
So the most specific type of a is unquely T2, but the value b could be of type T1, T2, or T3, and the most specific type is not unique.
So why is that a problem?
Marshall Received on Sat Jul 05 2003 - 18:44:37 CEST