In order to decide this, the question to ask is whether the relationship is a true 1 :: 1
or not.
If the relationship is a 1 :: 0..1
(i.e. every row in B will have a related row in A but the rows in A may not (all) have a row in B), then there should be a FOREIGN KEY
in table B (pk)
that REFERENCES A (pk)
. This is the most common situation and it is easy to be implemented in almost all DBMS.
If the relationship is a true 1 :: 1
(i.e. every row in table A will have a related row in table B - and vice versa), then there should be two foreign keys, one from B towards A and another from A towards B. This is also easy to declare but not so trivial to actually make it work.
The problem arises due to the chicken-and-egg problem: Which table should I first insert a row into? If we insert into A first, the foreign key (towards B) will forbid the insert. If we insert into B first, the foreign key (towards A) will forbid the insert this time.
In order to make this work, the 2 insert statements have to be in one transaction - and the foreign keys have to have been defined as DEFERRABLE
- i.e. checked at the end of the transaction. So, if you work in SQL-Server (or MySQL) you simply can't do this. If you are in Postgres or Oracle or any other DBMS that has implemented deferrable constraints, this is achievable.