Field note · July 21, 2025

What site actually contains in sensor-telemetry

8,000 rows, 3 distinct values, and the one fact about site that changes how you query it.

1 min read ·Data quality ·quality practice

Working through sensor-telemetry again. site is the column people trip over, so here is what it actually looks like.

8,000 rows, no nulls, 3 distinct values. NOR, RIV, or SLT.

3 values, and they are not evenly spread: NOR 35.3%, SLT 35.3%, RIV 29.4%. The largest takes 35.3% 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 site order by 1 will, in about a second.

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

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 3 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 3 categories reflows without warning. Values arriving is a schema change that no schema check catches.

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