Re: Foreign key problem
Date: Tue, 13 Jun 2006 18:30:06 -0400
Message-Id: <qsq3m3-60s.ln1_at_pluto.downsfam.net>
mAsterdam wrote:
> Kenneth Downs wrote:
> >>> In the limited example given in the post, yes.
> >>>
> >>> In fact we have half-dozen or so other flags on the FK table,
> >>> two of which combine to provide
> >>> multiple FK's between any two tables.
> >>> We employ a "suffix" and a "prefix" property, each of
> >>> which is used to alter the names of the columns in the
> >>> child tables by adding the obvious prefix or suffix
> >>> to each column in the child table.
>
> Yes, that is clear. What your example also showed is
> that what you consider the /obvious/ pre- or suffix
> may be borrowed from the place in the model rather
> than from the place in the universe of discourse (UOD).
>
> Say we have a database with games of bridge:
>
> Player(*Id, Ranking, ...
> Game(*G#, N_player, E_player, S_player, W_player, ...
>
> Here are four FK's in the same 'child' table
> referencing the very same 'parent' table (adopting
> your terminology for now). Terms from the place in
> the model (_parent, _child) do not help at all
> to distinguish the FK's.
> Terms from the place in UOD, specifically the /role/
> of the Player in the Game, do help: North, East, etc.
>
Your distinction of role (vs. pk) must collapse into the name of a column when we implement, no?
The FK definition I make also collapses into column names when we implement.
Upon implementation, we must necessarily create the same thing. Are you therefore just giving it a new name?
-- Kenneth Downs Secure Data Software, Inc. (Ken)nneth_at_(Sec)ure(Dat)a(.com)Received on Wed Jun 14 2006 - 00:30:06 CEST