Often a foreign key will refer to rows in more than one other table. Not all queries will want to chase all of those references.
Moreover, when you have a composite key, the foreign part may only be a subset of the entire key.
For example, if your Key is {Street,House}, you have a relation to another table which has a list of people inside that {Street,House} and you might also have a relation on {Street} to a table that contains metadata about that street as a whole.
The "Type" of the "row in another table" isn't a single thing: it would be different for all the different relations so it exists in the form of foreign key declarations which embody all the variability in the relation.
Comments
This is typed in the foreign key constraints DDL.
Often a foreign key will refer to rows in more than one other table. Not all queries will want to chase all of those references.
Moreover, when you have a composite key, the foreign part may only be a subset of the entire key.
For example, if your Key is {Street,House}, you have a relation to another table which has a list of people inside that {Street,House} and you might also have a relation on {Street} to a table that contains metadata about that street as a whole.
The "Type" of the "row in another table" isn't a single thing: it would be different for all the different relations so it exists in the form of foreign key declarations which embody all the variability in the relation.
Of course! I guess the saying is true that you sometimes can't see the forrest because of all the trees... Thank you.