Data Modeling Best Practices

Best Practice
1

When designing and implementing your app’s data model, it is suggested that these best practices are utilized to facilitate ongoing app development.

Grouping like-models
In your schema.xml, your models will generally be split into the following categories:

  • User data
  • Master data
  • Transactional data
  • System data

The schema.xml file should have these categories grouped as such.

Labeling models
To easily distinguish between the categories, the label for master data should be prefixed with “MSTR:” or similar. The label for system data should be prefixed with “SYSTEM:” or similar. The label for user data and transactional data do not require a designated prefix.

Defining fields
For master and transactional data, it is suggested that the following fields at a minimum are defined within each model:

  • Master data
    • archived (boolean): This field is particularly useful for sync rules. Archived data can easily be excluded from the sync rules.
    • name (text): This field will be used as the display name.
    • sequence (integer): This field can be used for ordering queries when the data should be sorted in a different manner than alphabetically.
  • Transactional data
    • archived (boolean): This field is particularly useful for sync rules. Archived data can easily be excluded from the sync rules.
    • created_at (datetime): This field will track the datetime that the object was created.
    • created_by (belongs-to user relationship): This field will track the user that created the object.

If data can be deleted in-app for certain models, it is suggested to use a soft-delete strategy and define the following fields on those models:

  • deleted (boolean): This field is particularly useful for sync rules. Deleted data can easily be excluded from the sync rules.
  • deleted_at (datetime): This field will track the date and time that the object was soft-deleted.
  • deleted_by (belongs-to user relationship): This field will track the user that deleted the object.

Choosing a display value
Each model has a display tag defined that defines how an object should be displayed to the user by default. The display can consist of static and variable text. Though not required, the display value is highly recommended as it is used as the default display in the Data Browser and within the app itself across various components, e.g., object-dropdown. It is suggested to always include the name field if applicable, as well as any commonly referenced fields for that object.

2

@anon31687946 great summary! I would also recommend anyone reading this to also look at this discussion regarding many-to-many relationships: How to setup a many-to-many relationship?

1 Like