Re: foreign key constraint versus referential integrity constraint

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) |
>
> }

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. 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. (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.

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.

It makes sense to me.

> > 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. ;)

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.

Marshall Received on Mon Oct 26 2009 - 06:17:02 CET