Required, unique, indexed

Three checkboxes on every field. They look similar — they do very different things.

Required

"Every record MUST have a value for this field."

The form refuses to save until the user fills it in. Use this for the fields you need to do anything useful with the record.

Use Required for:

• Names of people, organisations, things.
• Dates that drive logic (start of leave, due date).
• The status field.

Don't use Required for:

• Truly optional fields (notes, attachments, secondary phone).
• Fields a workflow fills in later (approver, approval timestamp).

Unique

"No two records can share the same value."

The form rejects a duplicate before saving. Use this for identifiers — values that should never repeat.

Use Unique for:

• IC numbers, staff IDs, badge numbers.
• Email addresses (if each person logs in with their own).
• Application numbers, invoice numbers.

Don't use Unique for:

• Names (two staff can be called Ahmad bin Ali).
• Dropdowns (statuses repeat by design).
• Free-text fields (descriptions, notes).

Indexed

"Make searches and sorts on this field fast."

This one is a performance hint, not a rule. Tick it when you expect to filter or sort by this field on the list page often.

Tick Indexed for:

• Fields you'll filter by — status, staff_id, date submitted.
• Foreign keys (links to other tables).
• Fields shown as default sort.

Don't bother for:

• Tables with under a few hundred rows — indexing won't matter.
• Fields you'll never search on (notes, descriptions).

Indexed fields use a tiny bit more disk space and slow down inserts very slightly. The trade-off is worth it on real production data.

Quick recap

The three are independent — you can mix any combination.

Where to next

• Defaults & validation — pre-fill values, add extra rules.
• Common mistakes — three constraint mistakes to avoid.