Subject | Re: [ib-support] General question about Master/Detail |
---|---|
Author | Helen Borrie |
Post date | 2002-10-24T00:55:29Z |
At 12:20 AM 24-10-02 +0000, you wrote:
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
>Hi there,Hey, this isn't Paradox, which relies on hierarchical keys! use the
>
>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?
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