对于大型的平面列表，避免使用Top Level

[#1]

大列表的顶级层的计算不能分割，因此随着列表的增长，计算将变得越来越低效。考虑一下你是否真的需要总数。如果需要获得总数，可以考虑添加中间父“总数”，以使计算更有效，也可以使用SUM进行聚合以进行验证

最佳实践的文章:
顶级项目和父层次结构

[Misbah]

对于大型平面列表，避免使用Top Level如果你需要总数，可以考虑添加假父母，使计算更有效

这是在前平面时代的做法．对于需要聚合的列表，我们通常为所有这些列表设置顶级级别，而不考虑列表的大小。下面的列表包含了超过100万个交易(为了便于理解)。

这个方法有什么问题吗？为了更好的理解，请看下面的截图。这是基于一个叫做选择性聚合的想法，即Anaplan会重新计算数据块来计算父块。

如果多伦多要改变，则需要计算所有其他城市，以便重新计算“所有城市”的最高级别。如果没有顶层，就不需要重新计算。然而，我们在层次结构中添加的级别越多，需要进行的计算就越少。

以下是平面设计的方法:把大名单分开，加上假父母。在包含100多万笔交易的早期列表中，我添加了5个虚拟父母。

注:添加假父母的过程可以发生在Anaplan内，也可以发生在Anaplan外。我认为它应该来自源系统，或者ETL层需要将这个大列表分割成多个(如果列表是动态更新的)。此外，一旦列表加载了虚拟父类，它应该始终是delta load之后。