Data model Checklist

• Choose folder structure strategy

• Create logging strategy

  • What events should be logged?

  • How long can they be stored?

• Define deletion and archiving strategy

  • Is Soft delete (IsDeleted) necessary?

  • Retention periods (GDPR or business rules)

  • Archival lists if applicable

1. Define the Storage Strategy (before project creation)

• Decide on shared or separate data models

• Choose folder structure strategy

• Define time handling strategy

  • Use a fixed (UTC) time zone

  • Or implement explicit time zone conversion logic

---

2. Define Folder Structure

• Feature focussed structure or Field function focussed

---

3. Identify Core Entities & Relationships

• Identify core application processes

• Define main data lists (e.g. Employees, Projects)

• Identify and define relationships between data entities

---

4. Classify Data Types

• Identify which data is persistent, temporary, or session-based

• Persistent database fields

• Temporary fields (Temp_) for UI and process logic

• Session fields (if Session Folder is used)

---

5. Define Prefixes Rules and naming convention

• Create naming guideline

• Apply prefixes consistently:

  • REF_ (references)

  • Calc_ (calculated fields)

  • Temp_ (temporary/transient fields)

  • OLD_ (deprecated fields)

---

6. Design Logging Strategy

• Determine if logging is required (and why)

• Define which events should be logged (and why)

• Define which information should be logged (and why)

---

7. Define Deletion & Archiving Strategy

• Decide where soft deletion or archiving is required

• Define retention periods (GDPR or business rules)

---

8. Apply Validation & Data Quality Rules

• Use valid value rules

• Use process validation rules where needed

• Set numeric min/max values

• Set maximum text lengths

---

9. Optimise Calculated Fields

• Ensure SQL-compatible and efficient expressions

• Review heavy or frequently used calculated fields

• Cache or persist calculated values when appropriate

---

10. Identify Performance Risks

Performance issues usually stem from design choices that only become problematic as data volume grows. Regularly review your data model to identify potential performance risks early.

Focus on:

• Large lists with high row counts

• Calculated fields used in overviews, dashboards, filters, or repeating UI components

• Heavy or unoptimised calculated field expressions (SQL compatibility)

• Large text fields (>1024 characters) in high-volume lists

• Rapidly growing logging or API-related lists

• Session fields that are updated frequently or shared unnecessarily across tabs

---

10. Review & Maintain the Data Model

• Remove unused fields

• Mark deprecated fields as OLD_

• Verify naming consistency

• Re-check validation rules

Periodically review performance and data growth