September 06, 2010     | Register
  
02

je vous propose ici un modele d'inner join fait à l'arrache mais terriblement efficace. Notre objectif est d'extraire certains champs et les transférer dans des variables. Le principe de l'inner est de fusionner deux tables selon des clés.

La structure d'un inner join est la suivante :

 

select <aliastable1>~<nomduchamps1> .... <aliastable1>~<nomduchampsn > <aliastable2>~<nomduchamps1> .... <aliastable2>~<nomduchampsn >

from <NOM DE LA TABLE1 > as <aliastable1> inner join <NOM DE LA TABLE 2> as <aliastable2>

on <aliastable1>~<nomduchampsclés1> = <aliastable2>~<nomduchampsclés2>

into <variable1> ... <variable n>

where <aliastable1>~<nomduchampscritère> CONDITION.

 

 

Dans la section on il es possible de définir plusieurs relations avec différentes clés en ajoutant de nouvelles relations avec AND.

Par exemple :

 

 select t1~name1 t1~lifnr
      from lfa1 as t1 inner join lfm1 as t2
      on t1~lifnr = t2~lifnr
      into (wa_t_out-name1, wa_t_out-lifnr)
      where t1~lifnr in s_lifnr
      and t2~ekorg in s_ekorg.

 

Vous n'avez plus qu'à faire que les variables soient des champs d'une work area et avec un append vous serez remplir un tableau interne.

Facile

Actions: E-mail | RSS comment feed |

Comments

Tuesday, March 02, 2010 7:25 AM
3 remarques importantes:

- les tables cluster, BSEG par example, interdisent les clauses INNER JOIN

- une vue fera le même travail, en simplifiant l'écriture. Faites une requête INNER JOIN sur 4 tables, faites une vue à la place, et vous comprendrez très vite.

- à la place de variables indiquées dans la théorie, utilisez une structure, ainsi que l'instruction INTO CORRESPONDING FIELDS. Plus sympa à écrire.


Cela étant dit, l'example marche très bien.
# Datawolf
Tuesday, March 02, 2010 1:20 PM
Je proscris le CORRESPONDING. Un renommage dans la structure et c'est un champ qui ne sera plus alimenté. C'est rapide, mais ça pourrit la maintenance !

Au sujet de l'INNER JOIN : déplacer un maximum de conditions du WHERE dans le ON fait gagner un temps d'exécution monstre !

Tuesday, March 02, 2010 1:27 PM
Il ne faut pas confondre la clause where et le on. Il y a une incoherence dans les propos, ou une explication détaillée à fournir.

Pour le corresponding, il ne faut pas oublier que l'ABAP SQL est systématiquement retranscrit dans le SQL de la base de données.

le corresponding simplfie la maintenance. Désolé.
# Datawolf
Tuesday, March 02, 2010 1:38 PM
WHERE / ON -> je ne confonds pas, je t'explique que le ON fait la jointure et que le WHERE restreint les enregs de cette jointure; si as un un WHERE field = 'valeur', remonte-le dans un ON et tu gagneras en perfs. Si tu ne me crois pas fais une trace.

CORRESPONDING : fais l'expérience de mettre un CORRESPONDING dans un pgm et d'ensuite renommer un champ de ta table, et on en reparle. Tu verras si c'est le projet qui est simplifié ou sa maintenance.
Tuesday, March 02, 2010 2:54 PM
Ce n'est pas une question de croyance, c'est une question de pédagogie.

Je crois même avoir expliqué la semaine dernière la création d'une trace SQL dans une formation que j'ai donnée. ST05, si mes souvenirs sont bons.

La jointure et la clause WHERE n'ont pas la même fonction, même si l'on peut écrire dans la clause where la relation entre les tables. C'est une syntaxe ancienne, qui marche toujours, et qui dépend de l'analyseur de requêtes de la base de données.

Suivant la taille des projets, de la volumétrie des données, j'imposerai ou non l'utilisation de la syntaxe avec CORRESPONDING. C'est une bonne instruction, qui facilite la maintenance.

Le fait de renommer une zone de table en plein milieu du développement est de l'incompétence du développeur ou d'un mauvais cahier des charges, et du non respect des règles de développement SAP. Cela ne remet pas en cause le CORRESPONDING

Bon, il me faut retourner sur mon livre, sur l'abap objet, j'ai du boulot. Et j'espère avoir tes critiques constructives là-dessus par la suite.


PS: Auncune moquerie ni mauvaise pensée. Je considère simplement qu'il ne faut pas prendre 1 exemple comme LA vérité absolue.
# Datawolf
Tuesday, March 02, 2010 3:14 PM
Tu te trompes. Dans ton raisonnement et dans mes intentions.
Tu écris "on peut écrire dans la clause where la relation entre les tables" alors qu'il s'agit de l'inverse. Et si les clauses n'ont pas la même fonction, rien n'empêche de faire des sélections dans le ON. Maintenant ce n'est qu'une recommandation SAP, tu fais ce que tu veux.
Au sujet du corresponding je ne parle pas du renommage pendant le développement, sinon je n'aurais pas évoqué la maintenance. Je te parle du renommage bien après, par un développeur qui ne connaîtra pas l'impact de son geste et à qui le système ne signalera rien.
Allez, je te laisse à ton abap abject (jeu de mot inside).

Post Comment

Only registered users may post comments.