在外键表中使用主键作为外键

Question

This may sound confusing and or simple but..

If I use a foreign key from Table B in Table A, which has a separate primary key. Do I need to include Table A's primary key as a foreign key in Table B?

Thanks!

========================================================================

EDIT:

Okay, let me try and clarify my question a bit.

In the case above, should I use Taco_ID as a FK in Table 2? Or is does it completely unnecessary?

Answer 1

In general, you don't usually make foreign keys bidirectionally like that. If you do, it means that the two tables exist in a 1-to-1 relationship: Each taco has a type, and each taco type can only be used by one taco. If you have a relationship like this, there's not really any reason to have them in separate tables, they could just be additional columns in the same table.

Normally foreign keys are used for 1-to-many or many-to-many relationships. A 1-to-many relationship would be if many different tacos can be of the same type. They each have Taco_Type_ID foreign key.

For a many-to-many relationship, you typically use a separate relation table.

CREATE TABLE Taco_Types (
    Taco_ID INT, -- FK to Table1.Taco_ID
    Taco_Type_ID INT, -- FK to Table2.Taco_Type_ID
    PRIMARY KEY (Taco_ID, Taco_Type_ID)
);

Answer 2

foreign keys and primary keys are SOMETIMES related, but not always. A foreign key in a table literally just means "whatever value is in this field MUST exist in this other table over ---> here". Whether that value is a PK or not in that other table is irrelevant - it just has to exist, and it has to be unique. That may fit the bill of being a primary key, but being primary is NOT required.

You can have composite foreign keys, eg in a (silly) address book, the child table you list a person's phone numbers in COULD be keyed with (firstname, lastname) , but that runs into the problem of "ok, which John Smith does this number belong to?".

Answer 3

In most databases, foreign key references must be to primary keys or unique keys (and NULL s are allowed). MySQL recommends this but does not require it :

However, the system does not enforce a requirement that the referenced columns be UNIQUE or be declared NOT NULL. The handling of foreign key references to nonunique keys or keys that contain NULL values is not well defined for operations such as UPDATE or DELETE CASCADE. You are advised to use foreign keys that reference only UNIQUE (including PRIMARY) and NOT NULL keys.

Do you need to reference primary keys for a foreign key relationship? First, you don't even need to declare foreign key relationships. I think they are important because they allow the database to maintain referential integrity. But, they are not required. Nor is there any semantic difference in queries, based on the presence of foreign keys (for instance, NATURAL JOIN does not use them). The optimize can make use of the declared relationship.

Second, if you are going to declare the foreign key, I would recommend using the primary key of the referenced table. That is, after all, one of the major reasons for having primary keys.