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能解决的事了。

 

猜你喜欢

转载自www.cnblogs.com/sapSB/p/11969537.html