Time
The day it happened depends on where you are standing
Difficulty 4/5Subscribers
A booking platform runs venues in different countries.
Two pieces of time, and they are not the same kind of thing:
- When a booking was confirmed. A single moment. Two bookings confirmed seconds apart must sort correctly no matter which country each was made from, and support has to be able to say which came first.
- Which day the booking is for. A local calendar day at the venue. A booking on the 5th of March in Tokyo is on the 5th of March, and stays the 5th for a viewer in São Paulo, in London, and for the venue itself. It is not a moment; it is a square on a wall calendar.
Also:
- Each venue has a time zone, and the schema has to know it, because a local day means nothing without knowing whose.
- A venue takes at most one booking per local day.
- Bookings belong to a venue that exists.
venues already exists, with its time zones.
The one thing that is fixed
2 relationsThe tests reference these names. Everything else is yours, and is what is being assessed: extra tables, extra columns, types, constraints, indexes.
venues
idnametime_zone
bookings
idvenue_idconfirmed_atbooked_day
The schema that already exists
This runs before your submission. Do not repeat it, extend it.
prelude.sql
CREATE TABLE venues (
id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
name TEXT NOT NULL,
time_zone TEXT NOT NULL
);
INSERT INTO venues (name, time_zone) VALUES
('Tokyo Hall', 'Asia/Tokyo'),
('Sao Paulo Room', 'America/Sao_Paulo');LOCKED
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…