Re: foreign key constraint versus referential integrity constraint
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sun, 25 Oct 2009 23:07:29 -0300
Message-ID: <4ae501a7$0$23744$9a566e8b_at_news.aliant.net>
>
> ...
>
>
> Obviously you wouldn't, you would have to name the type as well as the
> attribute. Personally, another alternative wouldn't bother me, eg.
> excluding both both attributes from the heading union.
Date: Sun, 25 Oct 2009 23:07:29 -0300
Message-ID: <4ae501a7$0$23744$9a566e8b_at_news.aliant.net>
paul c wrote:
>> paul c wrote:
>
> ...
>
>>> 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. >> >> It would be very illogical. Names are very important things. What does >> id mean if you pretend it means two mutually exclusive things?
>
> Obviously you wouldn't, you would have to name the type as well as the
> attribute. Personally, another alternative wouldn't bother me, eg.
> excluding both both attributes from the heading union.
A sometimes disappearing attribute that is the very basis for comparison? That makes no sense to me whatsoever. Received on Mon Oct 26 2009 - 03:07:29 CET