The key the business insists on renaming
Logistics tracks shipments leaving warehouses.
Every warehouse has a short code that humans use everywhere, such as SP01,
RJ02. It is printed on labels, typed into spreadsheets, and read out on the
phone. It is genuinely unique, and it is genuinely the thing people mean when
they say "which warehouse".
It is also not stable. Operations reorganises regions and renames codes, and they will not stop doing that because a database found it inconvenient.
What has to hold:
- Two warehouses can never share a code.
- A shipment always belongs to a warehouse that exists.
- When a code is renamed, no shipment is lost and none is left pointing at the old code. After the rename, looking up the warehouse's shipments by its new code finds all of them.
- A shipment's tracking number is unique across the whole company.
warehouses already exists, and its code is the primary key.
The contract
2 relationsThe tests reference these names. Everything else is yours, and is what is being assessed: extra tables, extra columns, types, constraints, indexes.
warehouses
code
shipments
idwarehouse_codetracking_number
The schema that already exists
This runs before your submission. Do not repeat it, extend it.
CREATE TABLE warehouses (
code TEXT PRIMARY KEY,
city TEXT NOT NULL
);
INSERT INTO warehouses (code, city) VALUES ('SP01', 'Sao Paulo'), ('RJ02', 'Rio de Janeiro');Nothing here yet. Run the tests while signed in and every distinct schema you submit is kept, newest first, so an earlier design can be read next to the one you would write now.
This one is for subscribers
The problem above is the whole problem, and nothing is hidden from it. What a subscription adds is the part that tells you whether your answer holds: a real Postgres runs your schema, a battery of hidden tests decides, and a design review reads what you wrote.
Checking your subscription…
