Re: Foreign key problem

From: Kenneth Downs <knode.wants.this_at_see.sigblock>
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

Original text of this message