Helen Borrie wrote:

>
> At 12:20 AM 24-10-02 +0000, you wrote:
> >Hi there,
> >
> >this is just a simple question about the way I have set up my
> >Master/Detail tables.
> >
> >In my Master, I have an Integer primary key. In my detail, I have
> >the same field set as a foreign key, and I also have another integer
> >field (keyF) which merely is used to make a composite primary key
> >for the detail. the keyF field is generated by a generator.
> >
> >I have it like this because there is no other field in the detail,
> >which, when mixed with the foreign key, will be guaranteed to be
> >unique.
> >
> >Is this OK, or not a good solution?
> >
> >Also, if this is an OK solution, in the Detail table which should be
> >the first field? The foreign key to the master, or the unique keyF
> >to the detail?
>
> Hey, this isn't Paradox, which relies on hierarchical keys! use the
> generated unique column keyF as the primary key of the detail table and let
> the foreign key to the master do its work uninhibited. The PK of the
> detail table is irrelevant to the FK relationship and there are 101 reasons
> (erm...a slight exaggeration) not to have the PK and the FK columns
> stepping on each other.
>
> Also, you can have multiple FKs in the detail if you want to, and let the
> same detail table be detail to different masters. You can't achieve this
> with Paradox-style keys.
>
> What you have (minus the composite primary key) is ideal.
>
> heLen

I just discovered the value of this last week. At first it seemed strange and foreign at
the same time; pun intended, but poorly done.

After careful thought and comparisons between the two methods, the method Helen describes
here makes things sooooo much cleaner and easier, even though it still seems a bit foreign
to me.

--
Raymond Kennington
Programming Solutions
W2W Team B