I think the FK will always refer to the primary_key of your table A
(matching column, ordering matters, same data type, column name not
necessary the same).
Hence, you need to have corpid, name in table B
or if corpid is sufficient to be the PK for table A, corpid in table B is
good enough.
Mike Oswald <moswald_at_mitec.net> wrote in article
<35591F47.1B5BFA47_at_mitec.net>...
> Maybe an obvious but not so obvious question...
>
> If I create a foreign_key (FK_xxx) for a table with a primary_key
> (PK_xxx) ... does it matter whether I create a concatenated key or do I
> need a seperate index to match the FK?
>
> Table A - w/unique index on (corpid, name)
> ----------
> corpid
> name
> master
> blah-blah
>
> Table B - fk to Table A (corpid)
> ---------
> corpid
> fieldb
> fieldc
>
> I shouldn't have to go through the trouble to have 2 indexes on Table
> A... one with the primary / unique concatenated index and another index
> just on the corpid?
>
> -Mike
>
>
Received on Wed May 13 1998 - 21:32:17 CDT
