Thanks for a excellent article explaining relationship types and how they are implemented in a databases using foreign and primary key constraints on tables. I am old school and have been a database designer for a many years. The line between conceptual modeling and relational modeling and physical implementation are often blurred. What I mean is, a conceptual model, often referred to as an entity relationship diagram or ERD, has entities and relationships. Entities are things of interest such as "people, places or things". They can be related by any of the three relationship types. Tables do not have "data modeling relationships", although they are related via foreign key constraints. I do not know of a database that can implement a 1:1 or m:m relationship between tables. As you demonstrated, a 1:1 relationship is implemented with a foreign key constraint and a unique constraint on the child foreign key column. And a m:m relationship between two entities is implemented as three tables and two foreign key constraints. By the way, I have seen the common table called many things (cross reference, association, bridge) but I like the idea of having a suffix or prefix plus the parent table names to indicate that they are implementing a many to many relationship between those two tables.
I have joined projects with existing databases and there are certain tables that are hard to modify without breaking the code. Usually these tables have implemented two different entities in one table which causes the problem. This can be prevented by analyzing all requirements to identify every individual entity and its relationships to other entities. I then identify the natural key and implement each entity and their relationships as tables and constraints following the standard practices as outlined in this article. I agree, if the bridge table has no children there is no need for a surrogate key. If it has children a surrogate key needs to be added. I am not wanting to start a flame war over surrogate keys, but it is my practice to use both natural and surrogate keys. Natural keys prevent duplicates. Surrogate keys are used as foreign key columns since an integer ID is usually more efficient in performance and storage space is reduced if the parent table's natural key is a compound key.