Why an order points to a customer
A database can store a customer’s details once and let many orders refer to that record by its ID. In a relational database, the order table’s customer ID is a foreign key: a value meant to match a customer’s ID in another table. A rule called a foreign-key constraint can prevent an order from referring to a customer record that does not exist.
When software needs an order alongside the customer’s current address, it combines the tables using that matching ID. This operation, called a join, lets the database assemble related information without storing a full copy of the customer record in every order.
Less duplication, fewer conflicting edits
The arrangement avoids a familiar failure: if an address is copied onto dozens of orders, changing it in only some copies leaves the database with competing versions. Keeping one customer record means there is one place to update the address, and later queries can find it through the customer ID.
That design is useful when the address represents the customer’s current contact information. But an order may also need to preserve the address used when it was placed—for shipping, receipts, or historical records. In that case, the system can keep a separate snapshot on the order. The key distinction is whether the database needs the customer’s current details or the details as they were at a particular moment.
Relational tables make these choices explicit: each row represents a record, and columns define the kinds of information it can hold. The ID is the small link that lets separate tables stay connected without forcing every record to repeat everything it knows.
