交易台仪表盘显各户之机遇总额。每户之总额乃汇总列。用户启仪表盘，睹总额，遂决。继而添新机遇，复查同户。其户之总额未变。
既十五分，刷新之，犹未变。及一辰，乃变。卷积之柱，其行恰如文牍所载，而众误以为实时之总括。
此乃计算之柱与卷积之柱之别，亦乃今者仪表板需时时更新所循之式。
此二柱之属
计算列：每读行即算其值。若列加他二列，每载行（表观、API唤、视行），Dataverse必算其和。结果恒新，盖因应需再得。
卷积之柱：依时序而算其值。其默认时序为每十二时辰，可调至每柱一时辰。卷积若求子记录之数，则于时序触发时读子记录之现态，存其结果，并供此存值，直至下次时序。
二者皆于方案中存其定义（即公式），于消耗之码中形貌无异。然运行之态，迥然相异。
各得其所则然
算得之列，其正有由：
- 公式所恃，惟本行之字，或取自亲体（依查寻）
- 运算简易（算术、字符串相接、条件）
- 每读必需其值之新
聚得之列，其正亦然
- 此公式遍合诸子记录（求和、计数、平均、最小、最大）
- 其下数据频变，然集计不必秒内即新
- 异步重算之约，可也
以次聚计之列，弗许焉。Dataverse阻之——其由在性能，一户之览，必触其机于众机之询，每载皆然。聚合乃平台之应：预计其聚，以缓存供之。
何以异步为患
欲求子记录之滚总者，常为商贾所询，彼观仪表盘之数，期其合乎实情。当用户告之团队曰："户形表之总应显所有相联机遇之数"，团队遂建滚总栏。仪表盘显此栏之数。
既而用户造机缘，察其户牖，所计之数已陈腐。于用户观之，此数谬矣。于平台视之，此数乃日程触发之最后一刻之实况。
其解，或抑用户之冀望（仪表盘依时序更新），或易其施为。
即时之总数：有三途可择。
当总额确需更新时：
其一：插件，每子项变动即更新存储之总额。
术业之後，有插件，施於機會之上（創、更金額、刪）。此插件更計算「頂級機會總數」於其上級賬戶，並書寫之。適於小量——賬戶有二百機會，每更新甚少，無妨。不適於大量——賬戶有二萬機會，更新頻繁，則每子變更皆成父書寫，而數據虛擬之執行管線開始限流。
宜于：中量级一对多之关系。
替代方案二：通过索引计算列之和。
汝不可自父集子，然可于子之计算列中，计其贡献于行。于Opportunity列中设acme_attributable_amount = IF(acme_is_counted, amount, 0)，再用此于任一消费者查询。消费者于读取时自行集之。
适于仪表盘，可运行FetchXML并具聚合运算（于单次查询中，于子项累加acme_attributable_amount）。若消费者为不可运行聚合查询之Dataverse表单或视图，则失效。
宜于Power BI报表、定制仪表盘，凡可掌控读查询之处皆可。
替代方案三：设一小时调度，兼配“刷新”按钮。
基线情形，当存卷。于表上添一钮，显引卷算，由CalculateRollupField SDK请。用户体验之：“吾方添子，今击刷新，总额更新。”
适于：爆用型仪表盘——基线可，显性刷新应“方改之”之需。
宜于销售管理之屏、交易台评审、用户洞悉刷新语义之境.
吾等所稽核于聚合
凡项目有三聚合列以上者，吾等每季稽核之：
- 聚合犹在用乎？聚合积聚——或为应一时之需而增，后需废而列存。已废聚合犹占时序之位。
- 时刻之序，其度合乎理乎？设一卷总，以十二时为期，而所据之实每时易变，则此卷总非唯陈旧，亦乃虚耗——十二时之窗，见变者众矣。
- 旧式之术，犹然正乎？卷总之定义中，滤器引据特定之状码/态码。若此等码于后继之版中易义，则卷总默然算得非是。
审计每案需时二十分钟。半时之内，至少可删一汇总；三分之一时，至少需调一日程。
了然：删去子项，不引致归并
童子之记数，若卷之更新，当童子立或其数易则更。童子亡，不更，必待时辰之新启乃更。
"孩删除"与"卷刷新"之间之窗，显虚夸之总数。此尤苦于稽查之境——用户删复本，总数犹示复本之贡献，竟达十二时辰。
其修有二：一为插件，施于子项删除之变（既施术后，显引叠算之复），一为时序益密。吾辈常择插件，若表支持删除，盖因时滞显于目。
其规吾辈所执
汇总列随附形式提示："此总计每N小时刷新一次。添加新记录后点击刷新，即可立即查看更新后的总计。"
该提示为单字段描述行，增之无碍，且可预防"为何数据陈旧"之票，否则每两周必至。凡吾所发之汇总，皆备此提示。凡吾所承之汇总，初遇即加。