As short as is practical. Use Alpha numeric to help identify modules from long names. There is no need to prefix modules in line with DISCO. It is better to align them with functional areas
Exception:
2.01-01a Space saving for User Facing Modules: User facing modules can be renamed to a more descriptive name if required to save on dashboard space, but be mindful of not cramming too much onto a dashboard as per the general design principles
Related to Rule:
4.02-10 Turn off the Module Name
Best Practice article:
Naming Conventions
Use functional areas to categorise modules
Use these to provide sections and ordering to the Modules list, but don't use Emojis
Related to Rule:
1.08-01 Don't use Emojis
Within functional areas, group "like" modules together. Design for the type of module and use the appropriate structures
Best Practices articles:
Best Practices for Module Design
Reduce Calculations for Better Performance
Formula-Structure-for-Performance
The DISCO convention is designed to categorise types of modules. Within a functional area you may have multiple types of modules
Exception:
2.01-05a Simple models: If the model is simple, DISCO can be used as the naming for functional areas
Related to Rule:
2.01-04 Use the DISCO methodology for Module design
Subsidiary views are difficult to work with and audit. Try and minimise their use especially for calculation modules; create groups of calculation modules instead with like dimensionality
Exceptions:
2.01-06a Display on Dashboards for analysis or filtering: Sometimes, to enhance the end user experience, attributes are needed to be shown on dashboards
2.01-06b Ratio Formulas: Numeric values for ratios need to be in the same module and are unlikely to need the full dimensionality
2.01-06c Synchronization for some dashboards: If you have dashboards that need to synchronize from a module, sometimes a specific line item is needed (Old UX)
2.01-06d Line items needed for sorting: Sometimes to facilitate a sort, the line items don't need the full module dimensionality
2.01-06e Reporting or Export modules: To utilize filtering in reports or to provide attributes for exports (model to model), you may need to have line items for the non-dimensional attributes. Ensure these are set as subsidiary views to minimize the calculations
Create all functions and filters relating only to time in separate modules. They will only re-calculate on model opening and when the time settings change
It is best practice to use a separate module for each time granularity (e.g. by week, month, quarter, year etc.)
Create a System module to support all standing data and attributes about the hierarchy (all levels). At a minimum have the code and parent as line items
Exception:
Best Practice article:
创建一个模块没有维度assumptions for Time, and other "SELECT" values. These are useful for global assumptions and general setting that are used throughout the model. they are also useful within an Application Lifecycle Management (ALM) set up
Related to Rule:
2.02-14 Avoid using SELECT
Turn off summary options by default. It is better to use SUM for any downstream aggregation if not all levels are needed
Exception:
2.01-10a All aggregation levels are needed: If all aggregation levels are needed, then it is faster to use the native aggregation than use SUM formula
Related to Rule:
2.03-01 Turn Summary options off by default
Best Practices articles:
Reduce Calculations for Better Performance
Formula Structure for Performance
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
Create Calculation modules to house sets of line items that use the same dimensionality. Avoid using Subsidiary views
Related to Rule:
2.01-06 Avoid using Subsidiary Views
Best Practices article:
Line Item Subsets Demystified
Decreasing the Length of Your Formulas
Keep the non-time-based data in a separate module from static attributes
Best Practice article:
Data Hubs Purpose and Peak Performance
Don't use Select levels combined with filters on the same hierarchy. It is a double filter and inefficient because both will be kicked off. Use one or the other. Setting a Boolean line item in a System module with 'none' as the summary option will often achieve the same result
Try and keep filters in separate System modules. They can then be reused for different modules. In the notes section, describe where and how this filter is used to prevent accidental deletion as the Reference By column will not list filters on views.
Related to Rule:
4.02-02 Keep Filters in separate modules
If not using for other reasons, use Data Tags to signify the DISCO category
Create separate modules for Access Drivers for relevant combinations to be reused. Use different line items for different settings if needed
Copying large modules, especially those with filters and many views, can take some time and block the model whilst doing so. For large modules, it is likely to be quicker to re-create the module
Related to rule:
If you are using lists instead of native timescale or native versions, ensure these lists are placed as the first two lists in the dimension order. This mirrors the native time and version settings which will improve performance when mapping between native time/versions and standard lists
Best Practice Article:
When creating a module, consider the scope of the calculation and only include the dimensions that are needed. If the formula doesn't return the value required, or errors, don't keep adding dimensions until it does; it is better to review the calculation itself. Check other modules; you may already have a calculation module with the relevant dimensions, so add the calculation in the existing module
Related to Rule:
2-01-04 Use the D-I-S-C-O Methodology for Module Design
Best Practice Article:
Avoid using multiple IFs. It is better to split the formula into more line items, use LOOKUPs or alternative constructs
Best Practices article:
Line Item Subsets Demystified
Decreasing the Length of Your Formulas
If it takes you longer than one simple sentence to describe what the formula is doing, it is probably too long. Try not to mix expressions
If the expression is repeated in the formula (or other modules), put it on a separate line item. “Calculate once, reference many times”
Treat text strings with caution. Try and avoid multiple joins and split common joins to separate line items.
Make use of IF ISBLANK() when joining text, if the strings are empty set to BLANK.
Related to Rule:
2.02-05 Create "joins" in smallest hierarchy
2.03-02 Try not to use TEXT as a format, or limit it as much as possible
Best Practices articles:
Formula Optimisation in Anaplan
If a text string join is needed, create the joins in the smaller lists first to minimize the size of the text strings
Related to Rule:
2.02-04 Text Strings
Best Practice article:
Formula Optimisation in Anaplan
It is faster to check A=B rather than A-B=0
Booleans take up 1/8th of the space as a number, so unless a numeric value is needed use TRUE or FALSE
SUM and LOOKUP used in the same expression generally cause large formula calculations and may cause intermediate relationship calculations especially if Time is a dimension or when the source and target structures are very different. Splitting them into different modules and line items considerably reduces the size of the intermediate calculations
Exception:
2.02-08a The LOOKUP is a constant:Where the LOOKUP line item is a constant, the formula will operate as a SELECT, so the performance implications are negated
Best Practice article:
Formulas and their effect on model performance
Utilize these summary methods to minimize the use of additional line items and IF statements
For long timescales, using PREVIOUS is faster than CUMULATE due to the number of "reads" required for the calculation. So, the expression should be: 'Calc line item' = 'data line item' + PREVIOUS('Calc line item') rather than CUMULATE('data line item')
Exception:
2.02-10a Short Timescales: Where the number of periods is small, Cumulate is faster
Best Practice article:
Performance Issues with Cumulate Over Lists
TEXTLIST() requires a lot of memory for calculations and should be avoided if possible, using two dimensional modules and Boolean flags with ANY is a good alternative. Other alternatives are using FIRSTNONBLANK as well as LASTNONBLANK.
Avoid direct references to list item. E.g. IF ITEM(list)=list.xx. Instead, attempt to use a SYS module with a line item having a boolean format as this makes the formula more dynamic (multiple members can use the same logic).
Don't use POST for simple data offsets. OFFSET, LAG or MOVINGSUM are more efficient
Avoid hard coding using SELECT if possible. Use a constants module and use LOOKUP instead
Exceptions:
2.02-14a Versions: It is OK to use SELECT for versions
2.02-14b For top level items on non-composite lists: In Non-Composite lists, it is not possible to use LOOKUP to return the value, so it is OK to reference the Top Level item with SELECT. For other items, it is better to use dummy parent lists and additional modules
Related to Rule:
1.01-01 Never use SELECT with Time
Doing a FINDITEM() on blank values is inefficient as the function has to traverse the entire list before it returns a blank.
If the majority of the values are not blank, then check for BLANK first:
If the majority are NOT blank:
If the majority are blank:
根据空格线工艺教育学院的数量m could have will dictate which formula to use. If there are more blanks than not, then use the second formula. If Line Item is more dense (has more values than not) then the first formula should be used. If there will never be blanks in the values, there is no need to check for blanks:
Related to Rule:
2.02-17 Put the most common condition first
In multiple conditional statements, try and include a conditional to prevent further referencing in the formula if the condition is satisfied
For formula efficiency, put the conditional with the most common occurrence first in the formula
The engine works more efficiently when calculations are broken up into separate line items. So, break up formula expressions where possible. This is especially true for calculations that are referenced many times and/or calculations that don't change that often
Best Practice articles:
Formula Structure for Performance
Formula Optimization in Anaplan
Always refer back to the ultimate source if possible, to avoid creating more dependencies than necessary. This allows more parallel calculations to be run increasing efficiency and speeding up calculations
Best Practices article:
Best Practices for Module Design
RANK is a calculation intensive formula that cannot multi thread. Used in conjunction with large lists it can lead to poorly performing calculations. The same applies to RANKCUMULATE
Exceptions to this are when the formula also applies to Time.
TIMESUM formulas should not be used in a line item that applies to Time, the formula will be duplicated for each time period.
如果TIMESUM使用时间然后考虑using MOVINGSUM instead.
Most line items in the model will not need summary calculations, so it is good practice to turn summaries off initially and add then back when necessary. This is especially true for Calculation modules and conditional formatting line items
Exception:
2.03-01a User facing modules on dashboards: For Input or Output modules, specifically those line items displayed on Dashboards, summary options are likely to be needed
Related to Rule:
2.01-10 Calculation Modules
Anaplan (as with computers in general) is optimized for numbers and Booleans. Text formats use more memory than any other format due to the way computers need to store the data. Minimize the use of text if possible.
Set to BLANK rather than leave empty or invalid text.
Related to Rule:
2.02-04 Text Strings
Ensure headers are set to No Data to avoid unnecessary calculations
Give the view a meaningful name (e.g. Dashboard Grid, Filtered View, Export etc.) There is no need to add the module name within the name of the view
Best Practice article:
Naming Convention
Filter on a Boolean and only have one filter per dimensional tab
Related to Rule:
4.03-01 Use efficient filters
Best Practice article:
Filter Best Practice
Keep the default view as is, no hiding line items, filtering, or conditional formatting
If possible, nest the dimensions in order of size (largest to smallest)