Re: foreign key constraint versus referential integrity constraint
From: paul c <toledobythesea_at_oohay.ac>
Date: Mon, 26 Oct 2009 00:05:47 GMT
Message-ID: <vJ5Fm.49370$Db2.12947_at_edtnps83>
>
> 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) |
> }
>
> ...
Date: Mon, 26 Oct 2009 00:05:47 GMT
Message-ID: <vJ5Fm.49370$Db2.12947_at_edtnps83>
Bob Badour 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) |
> }
>
> ...
Not that I'm advocating it but I imagine there would be nothing illogical if the model (just another word for 'interpretation') let the heading be (id in char(2), id in integer, name ... etc.) even if that's contrary to TTM, not to mention sql convention. Surely the problem has less to do the technical heading than with preferring a language to reference only by name? Received on Mon Oct 26 2009 - 01:05:47 CET