Field note · September 30, 2024
Five minutes with company_size in data-job-postings
3,500 rows, 4 distinct values, and the one fact about company_size that changes how you query it.
Someone asked what is in company_size on data-job-postings, and the honest answer took one query.
3,500 rows, no nulls, 4 distinct values. startup, scaleup, midmarket, or enterprise.
4 values, and they are not evenly spread: enterprise 29.6%, scaleup 28.0%, midmarket 23.6%, startup 18.9%. The largest takes 29.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 company_size order by 1 will, in about a second.
select
count(*) as rows,
count(company_size) as present,
count(*) - count(company_size) as nulls,
count(distinct company_size) as distinct_values
from data_job_postings;Low cardinality, stable values — this is a column you can group by without thinking about it, and a reasonable candidate for a chart facet. Check the distinct list, not just the count, because a stray casing variant hides in the count and shows up in the group-by.
Where this bites: a group-by on this column produces 4 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 4 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.