Re: foreign key constraint versus referential integrity constraint
Date: Tue, 27 Oct 2009 02:29:35 -0300
Message-ID: <4ae68544$0$23778$9a566e8b_at_news.aliant.net>
Marshall wrote:
> On Oct 25, 10:52 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote: >
>>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) |
>>>>}
>>
>>>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.
> > I don't see how that would work. An integer isn't type compatible > with a string. Is it?
It doesn't have to be compatible with a string. It only has to be compatible with TOP or the universal supertype. String doesn't have to be compatible with integer either. It only has to be compatible with TOP or the universal supertype.
> The other points you made seem to be variations on the > same question.
Indeed. I think it is an important point to understand because it is so easy to get wrong. The type of the joined attribute has to be TOP which has the union of all values and an empty set of operations (or actually a single "equals" comparison operation) not an empty set of values and the union of all operations.
>>>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!
> > Fortunately, I'm not hot any more. Now I'm thinking that > I haven't had any alcohol in a week or more. Maybe > a drink is in order? Plus, I think there is a cupcake in > a cupboard somewhere downstairs. I must away! > > Marshall
Having bathed each of my 3 dogs several times, I now have to wash the skunk smell out of the vestibule before it pollutes the house any more than it already has, when I would much rather just go to bed. Received on Tue Oct 27 2009 - 06:29:35 CET