A very confident wrong turn
In this invented example, a small equipment supplier receives an urgent order: deliver a replacement projector to Paris by Friday. The sales system says Paris. The warehouse system says Paris. Everybody agrees, which is unfortunate: the customer means Paris, Texas, and the shipping label points to France.
The failure began before the parcel moved. Two systems exchanged a familiar word and treated familiarity as identity. A city name is useful for a person reading a screen. It is weaker evidence for a machine deciding which place that screen describes.
Names help us find places
City describes a named settlement within a country. Pairing the city with its country immediately separates the two Parises in our example. That is a substantial improvement over joining every row whose city column contains the same text.
It is not a universal uniqueness guarantee. Names can repeat within one country too. A practical place identifier may need an administrative region, a source identifier, or an explicit geographic boundary. Those are illustrative modelling choices: the right evidence depends on what the dataset actually identifies.
The country story explains why a country code can travel between datasets more reliably than a free-form name. A city needs similar care, even when it lacks a convenient universal code.
The boundary inside the question
Suppose the supplier asks, “How many customers do we have in Paris?” Does Paris mean the municipality, the postal address locality, or the wider urban area? A clean spelling cannot decide. Neither can a map pin, unless the question defines which boundary should contain it.
This becomes particularly visible with population. A population figure and a sales figure might both carry the label Paris while describing different areas. Dividing them produces a crisp answer to a question nobody meant to ask. The denominator needs a boundary and a date, not merely confidence.
Three different reasons to be there
Back at the supplier, the customer's office is in Dublin, the projector belongs to a London organization, and its current location is Paris, Texas. These statements can all be true. A single cityId on a customer record cannot stand in for every relationship.
The asset story follows the same distinction between ownership and location. Billing country adds another: where an invoice is billed need not be where equipment stands or where a person lives.
Giving each relationship a name makes later questions less mysterious. “Customers by billing location” and “equipment by current location” become separate, answerable requests.
A destination needs a promise
The supplier fixes the address, but Friday introduces another question: Friday where? A country does not map to one time zone, and a settlement label is not itself a time-zone rule. The promised deadline belongs with an explicit interpretation, as due today demonstrates.
A useful city record therefore does more than spell a place correctly. It lets other records point to the intended place, preserves the evidence behind that match, and leaves each business relationship visible. The projector can finally travel to the right Paris. The report can follow it there.
