Re: Can FK be nullable/optional by design?

From: Bob Badour <bbadour_at_golden.net>
Date: Fri, 12 Dec 2003 13:06:15 -0500
Message-ID: <Vf6dnepaArIqnkeiRVn-tw_at_golden.net>


"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
> 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-)

Please allow me to hang an important point off of your post. The bind you find yourself in above is certainly not unique to you so there is no need to take this personally.

Your bind above demonstrates a very real pitfall of confusing knowledge of a specific tool with knowledge of fundamentals. I have seen numerous people fall into this specific pit throughout my career. I figure at least a 90% chance the tool you know is Erwin, and you are describing their "identifying" vs. "non-identifying" relationships.

I have seen people using this tool create schemas with ridiculous six and seven part compound primary keys and call it "normalization".

Your bind above also demonstrates the dangers of using a graphical crutch in place of real thought and analysis.

I respectfully suggest you will find yourself much more effective if you learn the fundamentals before the tools. Received on Fri Dec 12 2003 - 19:06:15 CET

Original text of this message