Re: foreign key constraint versus referential integrity constraint

Marshall wrote:

> On Oct 25, 4:15 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>

>>Marshall wrote:
>>
>>>On Oct 24, 12:13 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>>
>>>>Domains, however, define what is or is not joinable because natural join
>>>>applies the equality comparison to attributes with like names, and
>>>>domains define equality comparisons.
>>
>>>That may be the most practical perspective, but from a theoretical
>>>perspective, I find myself lately thinking that every value of every
>>>domain is theoretically able to be compared for equality with
>>>every value of every domain. If we are considering comparing
>>>an integer and a string, we can say with confidence ahead of
>>>time that the comparison will return that they are unequal.
>>
>>For the comparison, that's fine. But what is the type of the resulting
>>attribute? We are discussing natural join.
>>
>>Suppose we have 2 relations:
>>
>>state: {
>>      (id in char(2),name in string) |
>>            ('AK','Alaska'), ('NY', 'New York) ...
>>}
>>
>>inventory_bin: {
>>      (id in integer, contents in string) |
>>            ( 1, 'Soup' ), ( 2, 'Nuts' ) ...
>>}
>>
>>When we evaluate state join inventory_bin, we know the body is empty,
>>but what is the type of the id attribute?
>>
>>state join inventory_bin: {
>>      (id in ??,name in string,contents in string) |
>>}

Union not intersection. It has to be a type compatible with both integer and string.

> Since we know, as mentioned, that
> there are no values that are both ints and strings, we
> certainly know that whatever the type is, it will be
> uninhabited.

It's not the type that is uninhabited only the relation body. The relation body is empty not because the type is empty but because no integer values in the type happen to equal any string values in the type.

> (That is, it has no values.) So either "the
> intersection of int and string" or else simply the empty
> type, aka "bottom" or "void" or what have you.

It has to be "top" not "bottom".

> Now that I've said all that, I agree that there are
> good arguments for saying (how did you put it?)
> you get an error or a warning or something like that
> instead.
>
>

>>>I also am suspicious of the idea of allowing a domain designer
>>>to define equality. From a theoretical standpoint, the system
>>>ought to know enough to figure it out, and from a practical
>>>standpoint, I've seen enough class designers screw it up
>>>with subtle and annoying consequences. Damn them!
>>
>>I suppose in TTM, equality is implicit based on type and any arbitrary
>>possrep.

>>>Marshall
>>
>>>(Still hot; still grumpy.)
>>
>>Yeah, it was hot here today to. It got all the way up into the 50's F.
>>But to be fair, there was a nice gusty wind to take the edge off the
>>heat. ;)

Ouch! Received on Mon Oct 26 2009 - 06:52:25 CET