Five minutes with origin in flight-delays

Someone asked what is in origin on flight-delays, and the honest answer took one query.

8,000 rows, no nulls, 14 distinct values. Origin airport code.

14 values, and they are not evenly spread: DFW 7.6%, ATL 7.5%, LAX 7.5%, SEA 7.4%. The largest takes 7.6% on its own.

Read the distinct list rather than the distinct count. Casing differences and trailing whitespace produce values that look identical in a report and group separately in SQL, and the count will not show you that — select distinct origin order by 1 will, in about a second.

select
  count(*)                 as rows,
  count(origin)            as present,
  count(*) - count(origin) as nulls,
  count(distinct origin)   as distinct_values
from flight_delays;

14 values is past the point where a bar chart stays readable. Group the tail explicitly rather than letting a chart library decide which 6 categories to drop for you.

Where this bites: a group-by on this column produces 14 rows today. If it is a column an upstream system can add values to, it produces an unknown number tomorrow, and any dashboard laid out for 14 categories reflows without warning. Values arriving is a schema change that no schema check catches.

The grain is one row per scheduled flight, 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.