SAP常见查询组合

Posted 2020-11-24 sapsb

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了SAP常见查询组合相关的知识，希望对你有一定的参考价值。

做SAP开发的，SELECT是必不可少的。新语法出了不少‘新鲜‘的语法，用法也是五花八门。

新语法有新语法的好处，老语法有老语法的优势。

新语法里把很多的逻辑处理，分组，排重，内表处理全都放到一些关键字来处理。看起来是简化了代码，方便开发处理数据，但是缺少了必要的数据处理的思维逻辑，让人变得傻了。

SAP作为企业ERP中最大的BOSS，一直以来都不是以美观和高科技赢得口碑。作为一个使用者来说，ERP最理想的样子就是稳定，快捷，准确等。

在我看来，ERP是千万量级，亿级，十亿级，百亿级的数据处理，效率最高的才是最好的。

下面开始说说一些常见的SQL样例：

1，单独的select

一些简单的select是最基础的了。

SELECT result 
       FROM source 
       [[FOR ALL ENTRIES IN itab] WHERE sql_cond] 
       [GROUP BY group] [HAVING group_cond] 
       [ORDER BY sort_key] 
       INTO|APPENDING target 
       [additions]. 
  ... 
[ENDSELECT].

这是SAP的F1说明，emmm...首先这个select endselect不建议使用了。select table的时候就对应好into table。select...endselect是单条处理，多次IO交互。

SAP给的建议是少次数的数据库IO处理，短时间的数据库IO。

[GROUP BY group] [HAVING group_cond] 这个稍微常用点，在分组或者取聚集数据的时候可以加。
比如：查询MSEG中各移动类型的数量，加个Group by就可以直接取。例子如下（因为不是ECC系统，所以借其他表演示）：

  SELECTA~PROCESS_TYPE
         A~STAT_USER
         sum( ZAF_PRICE ) as ZAF_PRICE
    INTO CORRESPONDING FIELDS OF TABLE GT_ORDER
    FROM ZHSB_ORDER_INDEX AS A
    INNER JOIN CRMD_ORDERADM_H AS B
    ON A~GUID = B~GUID
    WHERE (GT_WHERE)
    AND A~SALES_ORG IN S_ORG
    AND A~PROCESS_TYPE = P_TYPE
    AND B~CHANGED_AT BETWEEN GV_FROM AND GV_TO
    GROUP BY a~PROCESS_TYPE a~STAT_USER.

这里就可以直接查询某些条件组合下的合计值。

2.关联查询：

常用INNER JOIN,LEFT OUT JOIN 等。

SELECT - JOIN 
Syntax 
... [(] {data_source [AS tabalias]}|join 
          {[INNER] JOIN}|{LEFT|RIGHT [OUTER] JOIN} 
             {data_source [AS tabalias]}|join ON join_cond [)] ...  . 
Addition: 
... ON join_cond 
Effect 
Joins the columns of two or more database tables in a results set in a join expression. A join expression links a left side to a right side, using either [INNER] JOIN or LEFT|RIGHT [OUTER] JOIN. A join expression can be an inner join (INNER) or an outer join (LEFT OUTER) or RIGHT OUTER) join. Every join expression must contain a join condition join_cond after ON (see below). The following applies to entries specified on the left side and on the right side:

LEFT和RIGHT是以谁为主的差别。上面的例子中已经有了INNER JOIN,下面再添加个文本的LEFT JOIN如下：

  SELECT A~PROCESS_TYPE
         A~STAT_USER
         C~P_DESCRIPTION
         sum( ZAF_PRICE ) as ZAF_PRICE
    INTO CORRESPONDING FIELDS OF TABLE GT_ORDER
    FROM ZHSB_ORDER_INDEX AS A
    INNER JOIN CRMD_ORDERADM_H AS B
    ON A~GUID = B~GUID
    LEFT JOIN CRMC_PROC_TYPE_T AS C
    ON A~PROCESS_TYPE = C~PROCESS_TYPE
    WHERE (GT_WHERE)
    AND A~SALES_ORG IN S_ORG
    AND A~PROCESS_TYPE = P_TYPE
    AND B~CHANGED_AT BETWEEN GV_FROM AND GV_TO
    GROUP BY a~PROCESS_TYPE a~STAT_USER C~P_DESCRIPTION.

注意*：LEFT JOIN里的字段不可以当作查询条件。（上面的WHERE CLUSE里不能有 C~字段）。

管理查询中还有个是

FOR ALL ENTRIES IN

很多人都不喜欢这个，觉得这个效率低，还没有INNER JOIN省事。^_^看怎么用吧，不要一竿子打死一船人。

SAP给的解释自己看F1，这里就不多说了，我说个用这个提效的例子：还是上面的LEFT JOIN。

SAP的JOIN是表之间的关联，当主表的数据量达到一定数量级，不管JOIN的是不是文本表，都会加重负担，比如说上面的SLECT中是先GROUP再取C表的描述还是先JOIN再取描述，然后一起GROUP呢？。

这时候怎么取文本表效率高，速度快呢？因为上面的SELECT已经有GROUP了，查出的结果内表数量可想而知很少很少。

注*：这里以及下面说的文本表不是具体指文本表，而是代指关联辅表。

这时候用FOR ALL ENTRIES IN来查文本表数据，然后循环loop处理，效率就上来了。

    SELECT * INTO CORRESPONDING FIELDS OF TABLE gt_order
      FROM CRMC_PROC_TYPE_T
      FOR ALL ENTRIES IN gt_order
      WHERE PROCESS_TYPE = gt_order-PROCESS_TYPE.

在主表后面再加个文本表，用用FOR ALL ENTRIES IN也就顺理成章了。

注意*：如果文本表本身数据量并不多，那么甚至还可以省略这个FOE ALL ENTRIES IN，直接取个全表也是可以的，这时候效率几乎相当的。

3.层级查询：

在一些复杂条件的查询中，很难去处理到底怎么查询才是最优的。下面列几个表，顺便说明其中的关系：

BUT000:BP主表

BUT020:BP地址关系主表

ADRC:地址主表

ADR2:电话主表

ADR3:FAX

ADR6:邮箱

（注*这几个表，关系相对明确，很多时候比这更麻烦）

如果这时候要按电话号码来查找BP，那么能想到的就是从ADR2->BUT020->BUT000

如果这时候是按BP来查，那么就是BUT000->BUT020->ADR2,ADRC...

如果按邮箱，邮编又是另外的情况了。

那么这时候怎么查询呢？一个select肯定不能完全解决问题的，不仅效率不能让人满意，结果也不一样就是想要的。

这时候分层级查询就很好的处理这种情况了。

设定LEVEL1,2,3等等。

REPORT zlytest112.

TABLES:but000,but020,adrc,adr2,adr3,adr6.

DATA:lv_level TYPE c.

SELECTION-SCREEN:BEGIN OF BLOCK blk01 WITH FRAME TITLE text-001.
SELECT-OPTIONS:
s_part FOR but000-partner,
s_name FOR but000-name1_text,
s_grop FOR but000-group,
s_rego FOR adrc-region,
s_tel  FOR adr2-tel_number,
s_fax  FOR adr3-fax_number,
s_emil FOR adr6-smtp_addr.
SELECTION-SCREEN END OF BLOCK blk01.


START-OF-SELECTION.
  "设置分级条件
  IF s_tel IS NOT INITIAL OR s_fax IS NOT INITIAL OR s_emil.
    lv_level  = ‘3‘.
  ENDIF.

  IF s_part IS NOT INITIAL OR s_name IS NOT INITIAL OR s_grop IS NOT INITIAL.
    lv_level  = ‘1‘.
  ENDIF.

  IF s_rego IS NOT INITIAL.
    lv_level  = ‘2‘.
  ENDIF.
  

  CASE lv_level.
    WHEN ‘1‘.
      PERFORM SEL_BUT000.
      PERFORM FOA_ADRC.
      PERFORM FOA_ADR2.
      PERFORM FOA_ADR3.
      PERFORM FOA_ADR6.
    WHEN ‘2‘.
      PERFORM SEL_ADRC.
      PERFORM FOR_BUT000.
      PERFORM FOA_ADR2.
      PERFORM FOA_ADR3.
      PERFORM FOA_ADR6.
    WHEN ‘3‘.
      PERFORM SEL_ADRX.
      PERFORM FOR_BUT000.
      PERFORM FOA_ADRX.
      PERFORM FOA_ADRX.
      PERFORM FOA_ADRX.
    WHEN OTHERS.
  ENDCASE.

具体的FORM里的代码就省了。这里是强关联关系，所以可以用一个SELECT就能替换调，但是效率就差了千万倍了。如果是弱关联，那么就不是一个SELECT能解决的事了。