Field
A field is a single named slot within a record that holds one piece of data about the entity that record describes — a customer record's "email" field, an order record's "ship_date" field. The term comes from database and file-format design rather than statistics, where the equivalent concept is a variable or column; "field" is the word used when talking about the structure of an individual record, while "column" is the word used when talking about that same slot across an entire table, and "variable" is the word used when talking about it analytically. All three point at the same underlying thing from three different angles — storage structure, tabular layout, and statistical role — and a working data practitioner moves between the three terms depending on which layer of the system they're discussing.
Every field carries a data type that constrains what values it can legally hold, and type enforcement is one of the earliest and cheapest places data quality problems get caught — or missed. A field typed as an integer rejects "twelve" outright; a field typed as a date rejects "next Tuesday." Relational databases enforce field types at write time, which is why malformed data more often enters a system through loosely typed formats — free-text form fields, untyped CSV imports, JSON with no enforced schema — where a date can be stored as a string in three different formats across the same dataset without anything rejecting the inconsistency until an analysis downstream breaks on it.
Required versus optional fields — whether a field can legally be left empty (null) — is a design decision with direct downstream statistical consequences, because a field that's frequently null forces every later analysis to decide how to handle missing data rather than simply computing on the field as given. A field marked "NOT NULL" in a database schema guarantees every record has a value, simplifying every query and calculation built on it; a nullable field pushes that complexity downstream to whoever analyzes the data later, who then has to decide whether missing values should be excluded, imputed, or treated as meaningful (a null "cancellation_date" field, for instance, usually means "still active" rather than "unknown," a case where the absence of a value is itself informative).
A computed or derived field is one whose value is calculated from other fields rather than entered or captured directly — "full_name" derived from concatenating "first_name" and "last_name," or "order_total" derived from summing line-item amounts — and the decision to store a derived field versus compute it on demand is a standard tradeoff in data modeling between query speed and consistency risk. Storing the derived value makes reads faster but introduces the possibility it goes stale if the source fields change and the derived field isn't recomputed; computing it on demand guarantees consistency but costs computation on every read. Database views and materialized views exist specifically to manage this tradeoff, offering derived-field convenience without manually maintaining redundant stored copies.
Field-level metadata — a field's name, type, description, and whether it's subject to compliance handling (personally identifiable information, financial data) — has become its own governance layer as organizations scale the number of tables and fields in active use, typically managed through a data catalog. This matters at scale because the question "what does this field actually mean and is it safe to use" stops being answerable by reading the schema alone once a field's name is ambiguous (a "status" field can mean a dozen different things across a dozen different tables) or its original author has left the organization, which is why field-level documentation is treated as a first-class deliverable rather than an afterthought in mature data organizations.
Read a field as the smallest addressable unit of a dataset's structure: its type and nullability decide what values can reach an analysis undistorted, whether it's stored directly or derived decides a tradeoff between speed and staleness risk, and as a dataset's field count grows, documenting what each one actually means becomes as important as the data itself.