Path: newssvr20.news.prodigy.com!newsmst01.news.prodigy.com!prodigy.com!rip!news.webusenet.com!feed2.newsreader.com!newsreader.com!news2.telebyte.nl!news.tele.dk!news.tele.dk!small.news.tele.dk!sn-xit-02!sn-xit-01!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Joe \"Nuke Me Xemu\" Foster" Newsgroups: comp.databases,microsoft.public.sqlserver.programming,comp.databases.ms-sqlserver,comp.databases.theory Subject: Re: Can FK be nullable/optional by design? Date: Fri, 12 Dec 2003 08:46:36 -0800 Organization: North American Marcab-Teegeeack Love Association Message-ID: <1071247622.443558@news-1.nethere.net> Reply-To: "Joe \"Nuke Me Xemu\" Foster" References: <1071189386.456990@news-1.nethere.net> X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4922.1500 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Cache-Post-Path: news-1.nethere.net!unknown@66.52.162.225 X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/) X-Complaints-To: abuse@supernews.com Lines: 36 Xref: newssvr20.news.prodigy.com comp.databases:49029 microsoft.public.sqlserver.programming:312278 comp.databases.ms-sqlserver:106561 comp.databases.theory:22947 "Tobes (Breath)" wrote in message ... > "Joe "Nuke Me Xemu" Foster" wrote in message > news:1071189386.456990@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-) 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 Sacrament R2-45 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!