Fields
Fields are like columns in a database. They belong to an object and have a name, label for display purposes, and constraints such as data type and uniqueness.
In Force.com, there are two categories of fields: standard and custom. Standard fields are fields that are created by Force.com for its own internal use, but are also available to users. They can be hidden from view and unused, but not completely removed or redefined. They are a part of the Force.com data model that is static, relied on to exist by other layers of Force.com technology. Examples of standard fields are Id (unique identifier) and Created By (the user who created the record). Custom fields are created by you, the developer, to store data specific to your applications.
Some important differences between Force.com database fields and relational database columns are described in the subsections that follow.
Logical, Not Physical Fields
When you define a new field for your custom object, Force.com does not create a corresponding field in its physical database. Instead, it associates your new field with an existing “Flex” field, a VARCHAR column of its generic data table. This provides Force.com with the flexibility to redefine data types, add richer data types, and perform other processing on the data outside of a database’s typically rigid rules. Although this implementation detail of Force.com is not relevant to learning how to use Force.com’s database, it does help explain some of its underlying behavior.
Unique Identifiers
Typical database tables include one or more columns to contain the primary key, the unique identifier for each row. In Force.com, every object has a standard field called Id. This field is automatically populated with an 18-character, case-insensitive, alphanumeric string to uniquely identify your records. Unique identifiers can also be expressed as 15-character, case-sensitive strings, and this is how they appear in the Salesforce user interface. In most cases, the two styles of unique identifiers can be used interchangeably. So when you are designing your Force.com database, there is no need to add a field to contain a unique identifier.
Validation Rules
Validation rules place restrictions on the values of a new or updated record. They prevent users and programs from inserting data that your application defines as invalid. Rules are defined in an expression language similar to the function language found in the cells of a Microsoft Excel worksheet. The validation rule in Listing 2.1 prevents a record from containing a Start Date greater than its End Date.
Listing 2.1 Sample Validation Rule
AND(
NOT(
ISNULL(Start_Date__c)
),
NOT(
ISNULL(End_Date__c)
),
(Start_Date__c > End_Date__c)
)
When the expression evaluates to true, it is treated as a validation failure. For the rule to evaluate as true, the value in the fields Start_Date__c and End_Date__c must be non-null, and the value of Start_Date__c must be greater than End_Date__c.
Formula Fields
Formula fields contain values that are automatically calculated by Force.com, derived from other fields in the same object or in different objects. They use the same expression language as validation rules.
For example, Listing 2.2 shows a formula for a field called Billable_Revenue__c.
Listing 2.2 Sample Formula Field
Billable_Revenue__c = Week_Total_Hrs__c * Rate_Per_Hour__c
Week_Total_Hrs__c and Rate_Per_Hour__c are custom fields. When a new record is inserted or one of the two fields is updated, the two fields are multiplied, and the result is stored in the Billable_Revenue__c field.
Rich Data Types
Force.com supports a few flavors of the typical string, number, date/time, and Boolean data types. It also supports richer data types that lend themselves to direct usage in user interfaces with prebuilt validation, input masks, and output formatting. The rich types are phone, picklist, multi-select picklist, email, URL, geolocation, and rich text area.
Picklists are particularly valuable, as they address the clutter of “lookup tables” dangling off most relational data models. These lookup tables often contain only a key and description and can be readily replaced with picklist fields. Internally, picklists maintain their own identifiers for values, allowing their labels to be modified without updating the records that reference them.
History Tracking
Most databases do not provide developers a way to track every change made to records in a table. Typically, this is something that is implemented using another table and some code. In Force.com, any object can have History Tracking enabled on it. Every field with History Tracking enabled that is changed gets a new record inserted in a corresponding History object containing the old and new values.
Note
Field history data can be subject to automatic deletion. Organizations created on or after June 2, 2011, retain their history data for 18 months. You can log a case with Salesforce to request a longer retention period. Organizations created before this date retain field history data indefinitely.