What Is the Difference Between a Record and a Field?
From the earlier reference collection. Read the current software blog.
A record groups the properties of one entity, while a field names one property shared by records in a dataset.
Think of rows and columns
In a table, a record is typically a row describing one entity or event. A field is a named property represented by a column. In a list of sensor observations, one record might describe one reading, and fields might include station ID, observation time, temperature, and unit.
This distinction helps both data publishers and users discuss problems precisely. “The record for station A17 is missing” points to a whole row or object; “the temperature field is missing” identifies one property across one or more records.
Use one row for one defined thing
A table is easiest to interpret when every row represents the same kind of entity. If rows describe readings, each should describe one reading rather than mixing station descriptions, readings, and daily summaries in the same table. Separate related entities into separate tables and connect them with identifiers when that structure is needed.
For example, a stations table could have one record per station, while a readings table has one record per measurement and a station_id field linking the measurement to its station. This avoids repeating a station’s full address in every observation.
Fields need stable meaning
A field name is not enough on its own. Document its type, allowed values, unit where relevant, and whether it may be absent. A field called time is vague; observed_at signals its role, and a description can specify the timestamp format and time zone.
Keep one field focused on one property. A single location string that combines latitude, longitude, and a landmark is hard for software to validate or use in calculations. Separate named fields or a well-defined nested object make the components explicit.
Check the model with examples
Before publishing, describe a representative record in plain language: what real-world thing or event does it represent? Then inspect each field and ask whether it describes that same thing. If the answer shifts between a station and a reading, the dataset may need another record type or table.
Clear records and fields make documentation shorter and transformations safer. Users can reason about what one row means, compare values in the same column, and build tools without relying on undocumented assumptions.