Re: Can FK be nullable/optional by design?

From: Tobes \(Breath\) <"Tobes>
Date: Fri, 12 Dec 2003 14:44:25 -0000
Message-ID: <brck8d$1t2ru$1_at_ID-131901.news.uni-berlin.de>


"Joe "Nuke Me Xemu" Foster" <joe_at_bftsi0.UUCP> wrote in message news:1071189386.456990_at_news-1.nethere.net...
> Did you really mean to claim that ALL non-nullable attributes MUST
> 'logically' be included as part of the primary key?!

Well, not really! I was just throwing in another option - where if the existance of one entity is dependent on another, then you can make the PK of that entity part of a composite key in the dependent entity. It's an alternative to just non nullable foreign keys, where the related column(s) become part of a primary key, rather than just a foreign key. Sorry, I think I need to take my anti-waffle pill, can't seem to put a good explanation together 8-)

> > Otherwise, if the Client could optionally belong to one Group, the
> > relationship would be captured in a link table, as you suggested in B?
> >
> > GroupedClient (PersonID PK/FK, GroupID FK NOT NULL)
>
> This would avoid the null nonsense until someone does an outer join.

That's true. So which option would you go for?

Tobes

> --
> Joe Foster <mailto:jlfoster%40znet.com> L. Ron Dullard
<http://www.xenu.net/>
> WARNING: I cannot be held responsible for the above They're
coming to
> because my cats have apparently learned to type. take me away,
ha ha! Received on Fri Dec 12 2003 - 15:44:25 CET

Original text of this message