Re: foreign key constraint versus referential integrity constraint

From: Bob Badour <>
Date: Mon, 26 Oct 2009 02:52:25 -0300
Message-ID: <4ae537db$0$23747$>

Marshall wrote:

> On Oct 25, 4:15 pm, Bob Badour <> wrote:

>>Marshall wrote:
>>>On Oct 24, 12:13 pm, Bob Badour <> 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) |

> Well. If the system is untyped, the question doesn't even
> come up. (Not that I would ever use such a system, but
> I mention it for completeness.)
> In a typed system, the type is whatever the intersection
> of int and string is.

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

> It makes sense to me.
>>>(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. ;)

> On the weekends I often hang out with my oldest daughter at
> the local Starbucks; I sip coffee and she people-watches. I
> sit and she prefers to stand. If we go in the afternoon that
> means I'm in the shade and she's not. Today we went at
> twelve thirty, and she got sunburned.

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

Original text of this message