Data dictionary and fields
How the data dictionary defines every field, which field types to choose, and the dictionary attributes that change platform behaviour.
How the data dictionary defines every field, which field types to choose, and the dictionary attributes that change platform behaviour.
- Field type is a data decision, changing it later is a migration
- Use dictionary overrides instead of duplicating fields on child tables
- Attributes control lookup, sorting and encryption behaviour
- Name fields with the u_ prefix in global scope so custom columns are obvious
The dictionary defines the table
sys_dictionary holds one record per field plus a collection record per table. Column name, type, length, default value, mandatory and read only all live here. Editing a field from a form opens the same record.
Choosing the right type
Type decides storage, indexing and how the field behaves in filters.
- String with a sensible max length, not 4000 for everything
- Choice for a fixed set of values, with the choices held in sys_choice
- Reference when the value is another record, never a string copy of its name
- True/False for flags, not a string with yes and no
- Date/Time for anything time based so timezone conversion works
Dictionary attributes
Attributes are the switches that most people never open. Common ones are edge_encryption_enabled, ref_auto_completer for reference lookup style, no_sort to keep a column out of sorting, and max_length behaviour for long text.
Dictionary overrides
On extended tables you can override the parent definition per child table: default value, mandatory and read only. This is how incident can require a category while other task tables do not.