Best Practices for Designing Models

Best practices for creating models

• Use the most suitable datatypes for datatable columns. Avoid string datatype when other datatypes can be be used:
  • If there are only two possible values, boolean is the best datatype. In booleans, the true and false values can be mapped into a textual presentation in charts, so it's not needed to use string datatype to get desired textual presentations.
  • If there is numerical data that cannot contain decimals or precision with decimals is not required, integer should be used.
  • If the data contains a numerical score (such as number between 1 and 5), integer is better than string.
• All datatypes support null values to mark missing or some other kind of special value. The null value can be used to mark anything, as it's just a matter of decision. In numerical values, using null is better than zero, as nulls can are ignored in calculations (such as average). Strings can also contain empty string value, which is different than the null value. Note also that booleans can actually contain three values: true, false and null.
• Include to models only those case and event attributes that are needed by the dashboards, because loading model is slower, when there are more attributes. For advanced analysis, such as finding root causes and clustering, more attributes maybe useful, but not for dashboards using only specific attributes.
• Include only those event types to models, that are needed by the dashboards. The more there are events, the more calculations take.
• For large models, the Load Model on Startup setting may be needed, so that the initial opening of dashboard isn't too slow, when the model is already available in the memory. On the other hand, loading many models automatically into memory, consume more memory, so models that are not used regularly, should not be loaded automatically into memory.
• Use concise event type names, as shorter are easier to read in the UI and they also provide slightly better performance. This is also valid for case and event attributes values. It's also better for readability, that if there are names that are close to each other, the differences would be in the beginning of the name rather than in the end, as the end may be cropped out if there is lack of space.
• Use the model description to document any relevant details regarding the model for other users. For example, the meaning of the event types and case/event attributes. The model description field can be found in the Model Properties dialog.