1.05-07 Avoid Top Level for large flat lists

rob_marshall

The calculation for a top level on a large list cannot be split so as the list grows, the calculation becomes increasingly inefficient.  Consider if you really need the total. If you need to have the totals, look to add intermediate parent “totals” to make the calculations more efficient, of use SUM to aggregate for validations

 

Best Practice article: 
Top Level Item and Parent Hierarchy

Misbah

Rule 1.05-07 Avoid Top Level for large flat lists If you need the totals, look to add dummy parents to make the calculations more efficient

Here is how it was done in Pre Planual Era. Lists that need to be aggregated we used to have a top level for all these lists irrespective of the size of the lists. Below list just contains over a million transactions (For the understanding purpose).

What is wrong with this method? In order to understand look at the screenshots below. It is based on the idea called Selective Aggregation which is Anaplan will recalculate blocks of data in order to calculate a parent block.

If Toronto were to change, all other cities would need to be calculated in order to recalculate the “All Cities” top level. If there were no top level, this recalculation would not need to occur. However, the more levels we add to the hierarchy, the less calculations need to occur.

Here is how it should be done in Planual Way: Split the large lists and add dummy parents in it. In the earlier lists containing more than a million transactions I added 5 dummy parents.

Note: The process of addition of dummy parents can happen within Anaplan or outside Anaplan. I would say it should come from the source system or the ETL layer needs to split this large list into multiples (If the list is being dynamically updated). Also once the list is loaded with dummy parents it should always be delta load after that.