Exactly one of them is the main one
People keep more than one address on file: home, work, the place a parcel should go this week.
The rules:
- One person can have many addresses. That part is ordinary.
- At most one of a person's addresses is the primary one. Two primaries is not a preference, it is a bug: the shipping label has to pick one.
- Two different people can each have their own primary. The rule is per person, not global.
- Deleting a person takes their addresses with them. Nobody wants an address belonging to nobody.
- An address always has a label, and it is one of
home,workorother.
Zero primaries is fine, because someone can add addresses and choose later.
people already exists.
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.
people
idname
addresses
idperson_idlabelis_primary
The schema that already exists
This runs before your submission. Do not repeat it, extend it.
CREATE TABLE people (
id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
name TEXT NOT NULL
);
INSERT INTO people (name) VALUES ('Ana'), ('Bruno');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…
