如何聚合内部表而没有循环并收集?

2020-08-19 02:01发布

         点击此处--->   EasySAP.com群内免费提供SAP练习系统(在群公告中)

加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)


嗨,

在启动Loop并实现业务逻辑之前,我想用相同的字符聚合内部表中的行。

我尝试使用"循环收集"将行从Itab1移到Itab2,这可以很好地工作,但是会花费太多时间。

我的要求是在我的逻辑在主循环中启动之前准备好内部表,以便容易汇总所有值。 我们有功能模块吗?

请提供任何可能的解决方案。

谢谢

(11.4 kB)

         点击此处--->   EasySAP.com群内免费提供SAP练习系统(在群公告中)

加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)


嗨,

在启动Loop并实现业务逻辑之前,我想用相同的字符聚合内部表中的行。

我尝试使用"循环收集"将行从Itab1移到Itab2,这可以很好地工作,但是会花费太多时间。

我的要求是在我的逻辑在主循环中启动之前准备好内部表,以便容易汇总所有值。 我们有功能模块吗?

请提供任何可能的解决方案。

谢谢

(11.4 kB)
付费偷看设置
发送
14条回答
粗暴的香蕉
1楼 · 2020-08-19 02:41.采纳回答

>>我尝试使用"循环收集"将行从Itab1移到Itab2,这可以很好地工作,但是花费太多时间。

您可以显示编码和数据定义以及定义" 很多时间"是什么意思? 您有多少行数据,聚合后有多少行,这需要多长时间,什么时间可以接受?

因为您不清楚需要做什么,所以我假设以下内容:

  • 您要么从数据库表中获取数据(请参阅1.中带有选项a。和b。),要么从其他输入中将数据获取到内部表中(请参见2。)
  • 您目前拥有 在内部表1中,两个"非唯一键字段"(例如,多个" 00001830"和" 50000844"条目)和另一个十进制值(例如,50,232.00)
  • 在内部表2中,您需要 键字段是唯一的(例如," 00001830"和" 50000844"只有一个条目),并且您希望共享相同键字段的所有值字段的总和

1。 如果可能,让数据库已经进行聚合。 数据库系统非常了解性能,因此,要传输到SAP的数据也更少。

"选项a。
 SELECT key1 key2 sum(value)
   从dbtable
   INTO TABLE sumtable"必须已经使用字段key1,key2,value进行定义
   在哪里(子句)
   GROUP BY key1 key2。


 "选项b。
 选择key1,key2,sum(value)作为sumvalue
   从dbtable
   到表@DATA(sumtable)
   在哪里(子句)
   GROUP BY key1,key2。
 

2。 如果由于某种原因无法进行数据库聚合,则需要使用基于SORTED或HASHED表的COLLECT语句,该表还具有两个键字段作为键。
ABAP文档对STANDARD表的说明如下:

>>规则
>>不要用行集合填充标准表
>>仅使用语句 收集具有唯一键的哈希表或排序表。
>>不要再将其用于标准表。

对于您的问题,您可以按以下方式进行操作:

"结构yourstructure包含字段key1,key2,value
 您的结构的数据不可分割的类型表。
 带有唯一键key1 key2的结构的数据可汇总类型哈希表。
 字段符号键入您的结构。

 环在不可分配的处。
  将收集到可汇总表中。
 ENDLOOP。

这是ABAP文档所说的方法:

>> COLLECT仅在要创建真正唯一或压缩的内部表时才使用。
>>在这种情况下,COLLECT可以极大地提高性能。
>>如果不需要唯一性或压缩性,或者由于其他原因保证了唯一性,则应改用INSERT语句。

希望有所帮助。

# p#

Quynh Doan Manh 当然,断言"最有效的方法是在数据库级别执行... "仅当数据来自数据库时才是正确的,我的意思是,如果数据来自其他媒体,请不要将其写入数据库以进行聚合;-)

,我看不到 为什么在没有看到原始代码的情况下,LOOP AT GROUP BY比COLLECT更快。 COLLECT非常快。 这取决于整个算法。

我是小鹏鹏啊
2楼-- · 2020-08-19 02:26

嗨,大家好,

每个人,非常感谢您为帮助我做到这一点所做的努力。

我想对正在发生的事情以及在哪里进行编码提供更多的信息(我将自己定为ABAP的新手)。

我正在将此数据加载到2个不同对象之间的BW(Datawarehouse)中,因此没有在DB级别进行聚合的问题,因此它完全在BW专家例程中的内部表之间。 要求是将BW-APD转换为BW4HANA转换。

下面是我要修复的Dev中的示例代码。

不。 记录数:445,656。

使用现有代码,需要22秒才能完成,而使用下面的代码,则需要4-5分钟(我想尽可能地靠近)。 因此,在此过程中,我发现最大的不同是在ITab中汇总具有相同特征的行。 (BW-APD接收聚合数据时速度更快,而在BW4HANA中,我必须对其进行聚合)

新代码:
 * SOURCE_PACKAGE是源对象和内部表
 * RESULT_PACKAGE是我尝试加载此数据的目标
 * ITAB是我尝试汇总的第二个Inetrnal表

 码:
     类型:开始于Y_SOURCE_FIELDS,
              GL_ACCOUNT TYPE/BI0/OIGL_ACCOUNT,
              FISCPER TYPE/BI0/OIFISCPER,
              FIELDNM003类型/BI0/OIFM_AMOUNT1," ECC
              FIELDNM001类型/BI0/OIFM_AMOUNT1," BW
              FIELDNM005类型/BI0/OIFM_AMOUNT1," BAL
            END OF Y_SOURCE_FIELDS。

     类型:开始于Y_TARGET_FIELDS,
            /BIC/ZRE_REC TYPE/BIC/OIZRE_REC,
              GL_ACCOUNT TYPE/BI0/OIGL_ACCOUNT,
              FISCPER TYPE/BI0/OIFISCPER,
            /BIC/ZSRC_AMT TYPE/BI0/OIFM_AMOUNT1,
            /BIC/ZTRGT_AMT TYPE/BI0/OIFM_AMOUNT1,
              CHRT_ACCTS类型/BI0/OICHRT_ACCTS,
              FISCVARNT TYPE/BI0/OIFISCVARNT,
              余额类型/BI0/OIFM_AMOUNT1,
            END OF Y_TARGET_FIELDS。

     数据:LS_SOURCE类型Y_SOURCE_FIELDS,
           LS_TARGET类型Y_TARGET_FIELDS,
           Y_SOURCE_FIELDS初始大小为0的ITAB类型标准表,
           WA TYPE Y_SOURCE_FIELDS。

 BREAK-POINT。
 * DELETE SOURCE_PACKAGE WHERE FIELDNM005 = 0。

 在SOURCE_PACKAGE ASSIGNING 处循环播放。
       将对应移动到LS_SOURCE。
       将LS_SOURCE收集到ITAB中。
     结局。

     删除ITAB WHERE FIELDNM005 = 0。

     向ITAB进发。
       将WA移动到LS_SOURCE。

       LS_TARGET-GL_ACCOUNT = LS_SOURCE-GL_ACCOUNT。
       LS_TARGET-FISCPER = LS_SOURCE-FISCPER。
       LS_TARGET-/BIC/ZSRC_AMT = LS_SOURCE-FIELDNM003。
       LS_TARGET-/BIC/ZTRGT_AMT = LS_SOURCE-FIELDNM001。
       LS_TARGET-BALANCE = LS_SOURCE-FIELDNM005。
       LS_TARGET-CHRT_ACCTS ='0010'。
       LS_TARGET-FISCVARNT ='V6'。

       I_COUNT = I_COUNT + 1。
 * LS_TARGET-/BIC/ZRE_REC = I_COUNT。
       将LS_TARGET移动到RESULT_FIELDS。
       将RESULT_FIELDS附加到RESULT_PACKAGE。
     结局。
 结局。

 

希望这很清楚。

感谢您的帮助:-)!

太Q了
3楼-- · 2020-08-19 02:29

请显示您的代码。 请说明它真正需要多少时间,以及多少数据。

作为信息,COLLECT基本上非常快,这当然取决于您执行它的次数。

# p#

如果COLLECT运行缓慢,则很可能是您没有使用HASHED表-或至少有一个使用正确定义的键的表。

(来源:我想我记得霍斯特·凯勒曾说过这一次)

Baoming ROSE
4楼-- · 2020-08-19 02:34

< a hraf=" https://people.sap.com/sandra.rossi"> Sandra Rossi

您说得对,收集速度很快。 我没有比较group by并进行收集,但是group by的事情是我可以控制组和聚合字段的键,为什么在收集时收集所有"数字"类型的字段(或者我不知道如何正确使用它:))。

昵称总是被占用
5楼-- · 2020-08-19 02:43

您可以从内部表中进行选择,我不知道是否支持聚合,但您可以看一下。

https://blogs.sap.com/2019/05/03/select-from-internal-table/

如果您使用的是HANA,那么我将进行CDS/AMDP聚合,因为HANA擅长使用7个小时的报告,而仅使用OPEN SQL中的SUM()就需要2分钟。

问候

Chaouki Akir ,这是SAP COLLECT和 肯定在NW 7.4和7.5中不使用STANDARD TABLE。 现在,Cant可以找到一种快速的方法来与以前的NW版本的其他在线文档进行比较。 有人知道如何快速便捷地做到这一点吗?