A field is a single attribute in a database record. In a customer table, fields might include first name, last name, email, phone, and signup date. Each field holds one piece of information about the record. The field has a data type: text, number, date, boolean. It may have constraints: required, unique, maximum length. The field is the smallest unit of data in a relational database.

Fields are defined in the schema. The schema specifies the field name, type, and constraints. Changing a field after data exists is possible but risky. Adding a field is usually safe. Removing one breaks queries that reference it. Changing a type can corrupt data if the conversion is not clean. Renaming a field breaks every query, report, and application that uses the old name. Field naming conventions matter. Consistent names make schemas easier to understand. A field called cust_email in one table and customer_email in another creates confusion. A field called status that means different things in different tables causes errors. Good field names are descriptive and consistent. They tell you what the data is without requiring documentation. Bad field names require a decoder ring.

Field properties

• Name — the identifier used in queries
• Type — text, number, date, boolean
• Length — maximum size for text fields
• Constraints — required, unique, default values
• Description — documentation of what the field contains

A field is a promise. It says what data the record contains. Break the promise and every query built on it breaks too.