Columns that refuse what should never be stored
A marketplace stores reviews of completed purchases.
Each review has three fields, and each has a rule the business already treats as non-negotiable:
- A rating from 1 to 5. Whole stars only: no 3.5, no 0, no 7.
- The amount paid for the purchase being reviewed. It is money: two decimals, and it has to add up exactly. A cent lost to rounding is a bug Finance will find.
- When the review was posted. Reviewers are in different countries, and "which day was that" has to have one answer for everyone.
Plus the obvious: a review belongs to a purchase that exists, and the same purchase is reviewed at most once.
purchases 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.
purchases
id
reviews
idpurchase_idratingamount_paidposted_at
The schema that already exists
This runs before your submission. Do not repeat it, extend it.
CREATE TABLE purchases (
id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY
);
INSERT INTO purchases DEFAULT VALUES;
INSERT INTO purchases DEFAULT VALUES;
INSERT INTO purchases DEFAULT VALUES;
INSERT INTO purchases DEFAULT VALUES;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…
