How Keys Connect Tables

Amelia Hart puts three lists on the desk: Members, Loans, Books.

She points at MemberID 1 in Members — Sophie Walsh of York — and finds every loan that also says MemberID 1. Two loans: The River Path and Northern Light.

She does the same from Books. BookID 1 is The River Path. Two loans say BookID 1: Sophie's, and Harry Cole's.

Nothing travelled from table to table. The same number appeared in two fields.

Members has a primary key. Loans has foreign keys that match it.

Loans.MemberID must match an existing Members.MemberID. Loans.BookID must match an existing Books.BookID.

That match is the relationship. Not a story. A repeated number that means “this loan belongs to that member” or “this loan is for that book”.

Trace MemberID 1: Members row 1 → Loans 101 and 102 → Books 1 and 3 on those loans.

Trace BookID 1: Books row 1 → Loans 101 and 103 → Members 1 and 2 on those loans.

Always connect on IDs. Names are labels.

Connecting tables by matching names instead of IDs fails the moment two people share a name. Join “Sophie Walsh” to “Sophie Walsh”. The London Sophie now shares loans with the York Sophie. Connect on MemberID. Names are labels. IDs are identity.