This article aims to provide a guideline for designing Processes, Dashboards, and Data Models with Entity Types in the Novunex Platform, resulting in optimal performance and extensibility of Novunex Platform apps.

Reasons for design guidelines

There are many reasons why design guidelines are helpful for developing a Novunex app.

• Create a common ground in process development
• Limit the source of errors
• Make debugging easier
• Improve performance

First, they provide a common ground for all team members to work from. This means that everyone has the same understanding of processes, entity types, and configurations. It also means that there is less chance for team collaboration errors since everyone follows the same steps and the same approach to build and test Novunex Apps. Second, design guidelines help us limit the source of errors by providing clear instructions on how to approach use cases and create easily understandable solutions. Third, design guidelines make debugging easier by ensuring that each part of the solution is extensible and maintainable. This allows us to determine where an issue may have occurred quickly. Fourth, design guidelines improve performance by ensuring that each feature and function of the solution is used in the way it was meant to be.

Entity Types

Limit the amount of Entity Type Attributes

• Rule - Do not use more than 24 Attributes per Entity Type
  • Reduces the IO bandwidth: The relational database server is incredibly efficient with its data access; however, if data is spread over more pages and blocks, then more IO bandwidth is required. To ensure that the database works as efficiently as possible, you should use no more than 24 attributes per Entity Type.
  • Reduces the cache size: The database stores data inside formatted database blocks, and these blocks are the basis of all caching mechanisms so that caches will store database blocks. Querying the database will move some read blocks into the query cache. The smaller a block is, the more blocks can stay safely inside the caches without having to drop them for new blocks from new queries.
• Rule - Favour short strings over strings if possible
  • Strings are not limited in length (size); this can lead to high space utilization if most values are close to maximum.
  • Unique constraints do not work with string types, and relocating data records to different pages can lead to more I/Os bandwidth needs.

Choose the most atomic / smallest data type

• Rule - Do not store numbers or decimals as strings
  • Storing numbers and decimals as strings will use more space, indexes will not perform as well, you can’t do arithmetic, the data is not self-validating because of type, aggregate functions like SUM will no longer work, the output may sort incorrectly, and you will need to CAST to use it as a number, causing a significant performance hit.
  • From a data governance and logic point of view, you should generally store numbers as numbers and decimals as decimals.
• Rule - Use numbers as look-up values
  • One way to persist look-up values is to assign a unique ID to each value, either an integer or a short string. A short string is sometimes used, as it seems easier for DBAs and other stakeholders to understand the raw data in the database. However, this approach has one major problem: all of the look-up values exist in two places: processes (configuration) and database. In case the naming of look-up changes, every value in the database must also be updated.
  • Strings as look-up values significantly increase the storage space needed in a database; therefore, simple datatypes such as integers are preferred over storing repetitive, redundant strings.
  • The performance of any query significantly decreases if String-based look-up values are used.

Reference Attribute naming

• Rule - Name the referenced attribute the same as the Entity Type being referenced
  • It improves the readability of the data model and allows the developer to quickly identify references and the referenced entity type.
  • Exception: If more than one attribute references the same Entity Type, use suffixes (e.g., CreationUser, ApproverUser)

Favor 1:n over n:m relationships in Entity Type references

• Rule - Avoid n:m and re-factor them into 1:n relationships
  • The Novunex Platform has robust support for many-to-many relationships. Referential integrity keeps relationships consistent with their underlying entities, and with Data Queries, you can efficiently combine them in queries. This contrasts Dashboards and their Widgets as well as Form Activities and their Form Controls, most of which lack support for work with n:m references providing easy traversal. As a result, process engineers have to use workarounds to handle many-to-many relationships in their processes.
  • The problem arises when we want to consistently work with a data model that represents real-life entities, like customers and orders, across our different applications. Many-to-many relationships are a natural part of this. Still, they’re hard to implement consistently across other parts of the system because they require coordination between different areas of responsibility (e.g., managing the relationship between customers and orders). This increases the complexity of the Application design and reduces the maintainability at the same time.

Processes

Limit the number of Activities in Processes

• Rule - Do not use more than 24 Activities in a Process
  • Too many Activities in one Process are hard to maintain, and changes in extensive Processes will create complex test case scenarios.
  • Splitting processes into sub-processes improves not only the readability but also the maintainability of Novunex Apps.

Favor “Start process” over “Connect” activities

• Rule - Avoid using Connect Activities in Processes
  • Connect Activities embed a complete sub-process in a parent process, which is in rare cases a legitimate way to incorporate existing functionality into a parent process. However, including sub-processes into parent processes increases the size of the existing process context, limiting the performance of the process execution engine (Connect inherits the full process context, including all variables from the parent process, making it difficult to find and identify problems).
  • Using Start process Activities, isolated process instances with dedicated input parameters are started. These sub-processes have clear interfaces and limit the scope of debugging to the sub-process.

Dashboards

Limit the number of Widgets on a Dashboard

• Rule - Do not use more than 7 Widgets per Dashboard
  • Too many Widgets on one Dashboard reduce the performance and speed of the system since every Widget accesses the API and needs data for its representation.
  • The essential element of your interface is the user. Your goal should be to simplify your interface to the point where all information presented on the screen will be valuable and relevant to the user’s task. This means you should examine every element and evaluate it based on the value it delivers to users. It must not be shown on a Dashboard if it doesn’t provide any value. Interfaces shouldn’t contain information that is irrelevant or rarely needed. Irrelevant information introduces noise in UI —it competes with the relevant information and diminishes its relative visibility
  • If all Widgets are relevant to a user, splitting them across different dashboards improves the usability in most cases.

More information