Field note · January 22, 2024

What country actually contains in data-job-postings

3,500 rows, 7 distinct values, and the one fact about country that changes how you query it.

1 min read ·Data quality ·quality practice

Working through data-job-postings again. country is the column people trip over, so here is what it actually looks like.

3,500 rows, no nulls, 7 distinct values. Country code.

7 values, and they are not evenly spread: US 45.1%, GB 12.5%, IN 11.9%, DE 9.5%. The largest takes 45.1% 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 country order by 1 will, in about a second.

sql
select
  count(*)                  as rows,
  count(country)            as present,
  count(*) - count(country) as nulls,
  count(distinct country)   as distinct_values
from data_job_postings;

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

Where this bites: a group-by on this column produces 7 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 7 categories reflows without warning. Values arriving is a schema change that no schema check catches.

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