Performance

2.01-13 Separate Transaction data from Attribute/Property data
Keep the non-time-based data in a separate module from static attributes Best Practice article: Data Hubs Purpose and Peak Performance
2.01-11 Keep the Dimension Order consistent
Ensure the dimension order is consistent among modules. Calculations are faster if the common dimensions are in the same order as the Applies To. The size of the list is not as critical as the order Best Practices article: Dimension Order
1.07-02 Line Item subsets for Version Formula
Use Line Item subsets to create different numeric formulae for each version to avoid multiple Ifs Best Practice article: Line Item Subsets Demystified Decreasing the Length of Your Formulas Variance Analysis With Native Versions Made Easy
1.05-12 Use formulas to derive properties of the list
Based off the code of the list it should be possible to derive the attributes; Calculating the values is more efficient than storing text fields Best Practices article: Data Hubs Purpose and Peak Performance
1.05-10 Never delete list and reload the list as a daily occurrence
Clearing and reloading a list increases the structural changes within a model and will increase the likelihood of a of model save, thus increasing the import time. It also removes pre-allocated memory block designed to increase efficiency. Use a unique key to update to values rather than delete and re-load. Also consider…
1.05-02 Always use a code
Using codes is more efficient for loading and using lists so strive to always have a code for lists. This is especially important for numbered lists Exception: 1.05-02a Static non hierarchy lists: For simple static lists (such as Yes/No) it is OK not to have a code, but even then, Y and N can be used as codes Related to…
5.07-09 Avoid using a Top Level for large lists of transaction data
Don't create a transaction list with a top level. The calculations will need to sum for all items in the list even if only a single item is added Exception: 5.07-09a Check totals: If a check total of all transactions is needed, but again using the flat attributes modules is preferable Related to Rule: 5.07-10 Add…
5.07-10 Add intermediate sub totals to transaction lists
If you need the totals for validation purposes, create intermediate subtotals within the transaction list. This will significantly reduce the calculation load Related to Rule: 5.07-09 Avoid using a Top Level for large lists of transaction data
5.07-08 Pre aggregate for downstream exports
It is more efficient to aggregate the data in the hub and then export it, rather than accumulate it through the import to the downstream models
5.07-07 Keep Transactional Analysis out of the planning models
Use the Data hub (or another reporting model) to keep detailed transactional data out of the main planning models. Large amounts of historic transactional data can inflate the size of the planning model and lead to reduced performance.
5.07-06 Master data should be built by the source system
Try and avoid creating Master Data in the hub. This should really come from the source system(s)
5.07-05 Use System modules
Use System modules for filtering data (current period, current FY year, etc.) Related to Rule: 2.01-15 Filters in separate modules Best Practice article: Filter Best Practice Data Hubs: Purpose and Peak Performance
5.07-04 Get the correct format
Get the data from IT in the correct format as well as the correct granularity Related to Rule: 5.04-06 Import the correct granularity
5.07-03 Flat lists for data export
Use the flat list structures to create modules and views for downstream exports
5.07-02 No Analytical modules
Try and keep Analytical modules out of the Hub
5.07-01 No Hierarchies
There should be no need for composite list hierarchies in the Hub. They can be built to "test" the actions, but after testing they should be deleted Exceptions: 5.07-01a Validation purposes: If data is needed to be consolidated to check against source systems, although the flat modules with attributes can be used to sum…
5.05-04 Ensure view filters are optimized
Only use one filter criteria...If more are needed, combine them into one line item Related to Rule: 4.02-01 Use efficient filters Best Practices article: Filter Best Practice
5.05-03 Split views for List and Module imports
Create two views from a source module. One for the import to the list (using name, code and parent), and a view for the attributes to the associated System module Related to Rule: 5.05-02 Only include what is needed
5.05-02 Only include what is needed
Only include the line items that are required for the import. Create multiple views if the module is used for different imports. The number of columns in the view does affect the speed of the import. The fewer the columns, the faster the import will be
5.04-08 Never use a list as an import source
Import sources should always be done from a module view. This allows for filtering and only including the elements required for each import
5.04-07 Import using the correct formats
Line items holding the Imported line items should reflect the data. List formatted, numbers, and dates. Don’t use text (unless it is a true text field)
5.04-06 Import the correct granularity
Only imported data at the granularity needed. There is no need to bring in transactional data at a weekly level when Planning happens at the month level
5.04-05 Pre aggregate in the source
Wherever possible, aggregations should be done in the source system. This is likely to reduce the size of the import file meaning faster imports
5.04-04 Only include the fields that are needed
Use the Ignore field if there are any unwanted fields in the source data
5.04-02 Create separate files for attributes and data
The data file should have the key and values based on the dimensions. Non dimensional data should be in a different file Related to Rule: 5.04-01 From source system, create a code defining all attributes Best Practice article: Data Hubs: Purpose and Peak Performance
5.04-01 From source system, create a code defining all attributes
Ideally, this would be a separate file that is unique vs. using the same file for the transactional load Exception: 5.04-01a Code is >60 characters: If the code is >60 characters, you will have to use combination of properties Related to Rule: 5.04-02 Create separate files for attributes and data Best Practice article:…
5.02-02 Keep actions in a process to a minimum
Each action in a process triggers a recalculation so try and minimize the number of actions
5.01-03 Keep User actions (in general) to a minimum
Critically review the need for user driven actions, consider the effect on user concurrency. Attempt to use formulas instead. This may need additional modules, but the user experience could be improved as a result
4.03-02 Keep Filters in separate modules
Try and keep filters in separate System modules. They can then be reused for different modules Relate to Rule: 2.01-15 Filters in separate modules
3.06-02 Instructions
Use text and instructions where possible, although keep it simple and don't overwhelm the user with verbose language

Performance

Discussion List