Field note · September 10, 2026

Keeping one row per key in data-job-postings

deduplicate by rank against a real schema, and the clause in it that is doing the work.

1 min read ·Analytics engineering ·sql

Keeping one row per key in data-job-postings comes up often enough to be worth a note. data-job-postings is a convenient thing to try it on — 3,500 rows, one row per posting.

sql
select *
from (
  select *,
         row_number() over (partition by posting_id order by posted_on desc) as rn
  from data_job_postings
) ranked
where rn = 1;

The ordering column is the whole decision. row_number() always returns exactly one row per partition, even when two rows tie — which is why it beats distinct on and group by + max for this: you get determinism, and you get every column of the winning row instead of a re-join to fetch them.

Run it against the real file in the SQL playground — the engine there is enough of a SQL implementation to execute this as written, and the dataset is already loaded. The pattern page has the version with the failure modes spelled out.

Window functions are the difference between SQL that describes rows and SQL that describes sequences. Almost every "we exported it to pandas to do this bit" turns out to be one of these five.

AE

Analytics engineering

Turning warehouses full of raw tables into models an analyst can trust without asking anyone.

Dimensional modelling, grain, slowly changing dimensions, metric definitions, and the SQL that survives production. Most "we need a data scientist" problems are "we need one correct table" problems.

Related

All field notes    2026 archive