Field note · March 21, 2024
What ticket_id actually contains in support-tickets
4,000 rows, all distinct, and the one fact about ticket_id that changes how you query it.
Working through support-tickets again. ticket_id is the column people trip over, so here is what it actually looks like.
4,000 rows, no nulls, 4,000 distinct values. Ticket identifier.
4,000 distinct values across 4,000 rows, so it is unique and a candidate key.
Uniqueness is a property of the data you have, not a guarantee about the data you will get. Nothing in the file enforces it; a re-export with an extra row, a merged upstream table, or a backfill that runs twice all break it, and none of them raise an error.
select
count(*) as rows,
count(ticket_id) as present,
count(*) - count(ticket_id) as nulls,
count(distinct ticket_id) as distinct_values
from support_tickets;Unique today is not the same as declared unique. If nothing tests it, the day it stops being unique is the day a join starts fanning out quietly.
Where this bites: the failure is silent in both directions. A duplicated key produces too many rows and a total that is too high; a missing one produces too few and a total that is too low. Neither errors, and both look like a real change to whoever reads the number.
The grain is one row per ticket, which is the context every one of those numbers depends on. None of them survive a change of grain, which is why "profile the column" and "profile the table" are the same job. Full schema, and the CSV, on the dataset page.