Re: Can FK be nullable/optional by design?
Date: Fri, 12 Dec 2003 08:46:36 -0800
"Tobes (Breath)" <tobin_dont_spam_me_at_breathemail.net> wrote in message <news:brck8d$1t2ru$1_at_ID-131901.news.uni-berlin.de>...
> "Joe "Nuke Me Xemu" Foster" <joe_at_bftsi0.UUCP> wrote in message
> > 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-)
The ClientID by itself should probably be the primary key, though the GroupID could be made part of an alternate candidate key.
> > > 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?
Maybe have a special "Loners" group? =) It's hard to say given the information at hand. Yeah, I know, the usual cop-out...
-- Joe Foster <mailto:jlfoster%40znet.com> Sacrament R2-45 <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 - 17:46:36 CET