Re: Foreign key problem
From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Wed, 14 Jun 2006 00:59:57 +0200
Message-ID: <448f436d$0$31640$e4fe514c_at_news.xs4all.nl>
>>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.
Date: Wed, 14 Jun 2006 00:59:57 +0200
Message-ID: <448f436d$0$31640$e4fe514c_at_news.xs4all.nl>
Kenneth Downs wrote:
> 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?
No. Why?
> The FK definition I make also collapses into column names when we implement.
You must have some difficulties with multicolumn keys, then.
> Upon implementation, we must necessarily create the same thing. Are you > therefore just giving it a new name?
No, I'm trying to point out that when modeling something one should keep looking for clues by looking at that something more closely, and not to easily give in to the inclination to shift down by looking at just the model. Received on Wed Jun 14 2006 - 00:59:57 CEST