Re: Foreign key problem

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@(Sec)ure(Dat)a(.com)