标签:express into 交互 时间 问题 erp epo ecif ons
做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能解决的事了。
标签:express into 交互 时间 问题 erp epo ecif ons
原文地址:https://www.cnblogs.com/sapSB/p/11969537.html