A record of who changed what, that nobody can change
HR keeps salaries. Legal keeps asking who changed them.
What the audit has to do:
- Every change to an employee's salary leaves a record: the employee, the old amount, the new amount, and when. Nobody should have to remember to write that record. Updating the salary is what creates it.
- A change that does not move the salary is not a change and does not deserve a row.
- The log is append-only. Once a row is written it cannot be edited and it cannot be deleted. An audit trail that the audited party can rewrite is not evidence of anything.
- The salary itself stays editable. This is a log, not a lock.
employees already exists, with salaries in it.
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.
employees
idnamesalary_cents
salary_changes
idemployee_idold_centsnew_centschanged_at
The schema that already exists
This runs before your submission. Do not repeat it, extend it.
CREATE TABLE employees (
id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
name TEXT NOT NULL,
salary_cents INTEGER NOT NULL CHECK (salary_cents >= 0)
);
INSERT INTO employees (name, salary_cents) VALUES ('Ana', 500000), ('Bruno', 600000);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…
