Join nur für bestimmte Tabelleneinträge Beispiel MARA/MARC

Alles rund um die Sprache ABAP®: Funktionsbausteine, Listen, ALV
19 Beiträge • Seite 1 von 2 (current) Nächste
19 Beiträge Seite 1 von 2 (current) Nächste

Join nur für bestimmte Tabelleneinträge Beispiel MARA/MARC

Beitrag von Bitfummler (Specialist / 111 / 4 / 3 ) » 28.02.2005 14:09
Hallo,

ich suche eine unkomplizierte Lösung für folgende Aufgabe (dieses Beispiel ist nur vereinfacht dargestellt):

Ich möchte mit einem Select-Join die mara und die marc in eine interne Tabelle lesen. Sogesehen erstmal easy! 8) Ich will jedoch nur mara-marc-saetze, bei denen zur materialnummer die werke 1 + 2 existieren. existiert nur das werk 1 oder nur das werk 2, so moechte ich diese saetze nicht in der tabelle haben. :?:

ich will einen loop ueber die interne tabelle mit entsprechenden gruppenwechsel und delete vermeiden.

haette da jemand eine idee? :idea:

bitfummler


Re: Join nur für bestimmte Tabelleneinträge Beispiel MARA/MA

Beitrag von ereglam (Top Expert / 1826 / 0 / 5 ) » 28.02.2005 14:35
Bitfummler hat geschrieben:Hallo,

ich suche eine unkomplizierte Lösung für folgende Aufgabe (dieses Beispiel ist nur vereinfacht dargestellt):

Ich möchte mit einem Select-Join die mara und die marc in eine interne Tabelle lesen. Sogesehen erstmal easy! 8) Ich will jedoch nur mara-marc-saetze, bei denen zur materialnummer die werke 1 + 2 existieren. existiert nur das werk 1 oder nur das werk 2, so moechte ich diese saetze nicht in der tabelle haben. :?:

ich will einen loop ueber die interne tabelle mit entsprechenden gruppenwechsel und delete vermeiden.

haette da jemand eine idee? :idea:

bitfummler
was Du suchst, nennt sich Subquery.
Hierbei bildest Du Deinen Join wie gewohnt, gibst aber in den Bedingungen mit, die selbst eine reduzierte SQL-Anweisung darstellt (=> Subquery).
Schau Dir dazu mal bitte die Hilfe zum 'SELECT -> WHERE -> logische Bedingungen' an.

grob sähe das so aus:

Code: Alles auswählen.

SELECT >Feldliste<
       FROM MARA
         INNER JOIN MARC
         ON  marc~matnr EQ mara~matnr
       WHERE 
         EXISTS
           ( SELECT FROM marc 
               WHERE matnr EQ mara~matnr
               AND   werks EQ >werk1< )
       AND
         EXISTS
           ( SELECT FROM marc 
               WHERE matnr EQ mara~matnr
               AND   werks EQ >werk2< ).
QED

Beitrag von Bitfummler (Specialist / 111 / 4 / 3 ) » 01.03.2005 07:13
Hallo ereglam,

vielen dank fuer die promte antwort. stimmt: die subquery gibt's ja auch noch.

noch eine frage hierzu: was sagt die performance zu diesem select? gerade mit derartig grossen tabellen..

gruss
bitfummler

Beitrag von Bitfummler (Specialist / 111 / 4 / 3 ) » 01.03.2005 07:21
Hallo ereglam,

vielen dank fuer die promte antwort. stimmt: die subquery gibt's ja auch noch.

noch eine frage hierzu: was sagt die performance zu diesem select? gerade mit derartig grossen tabellen..

gruss
bitfummler

Beitrag von Bitfummler (Specialist / 111 / 4 / 3 ) » 01.03.2005 07:24
Bitfummler hat geschrieben:Hallo ereglam,

vielen dank fuer die promte antwort. stimmt: die subquery gibt's ja auch noch.

Ich bekomme jedoch die Fehlermeldung "FROM" konnte nicht interpretiert werden. Mögliche Fehlerursache: Falsche Schreibweise oder Kommafehlr.

was habe ich falsch gemacht?

DATA: gt_marc TYPE TABLE OF marc,
gs_marc LIKE LINE OF gt_marc.

SELECT mara~matnr mara~ernam mara~aenam
INTO (mara-matnr, mara-ernam, mara-aenam)
FROM mara
INNER JOIN marc
ON marc~matnr = mara~matnr
WHERE
EXISTS
( SELECT FROM marc
WHERE matnr = mara~matnr
AND werks = '0101' )
AND
EXISTS
( SELECT FROM marc
WHERE matnr = mara~matnr
AND werks = '0105' ).

und noch eine frage hierzu: was sagt die performance zu diesem select? gerade mit derartig grossen tabellen..

gruss
bitfummler

Beitrag von ereglam (Top Expert / 1826 / 0 / 5 ) » 01.03.2005 08:50
nun, mir ist wohl beim Aufschreiben des Grundgerüsts (aus dem Kopf) ein Fehler unterlaufen: in den Subqueries muss zwischen dem SELECT und FORM ein '*' oder ein einzelnes Feld eingefügt werden.

Andererseits hätte ein Blick in die Hilfe helfen können, da ich nur ein Grundgerüst und nicht die vollständige Lösung liefern wollte...
Gruß
Ereglam


May the Force be with your code
|| .| |.|| | .... . ..|. ||| .|. |.|. . |... . .|| .. | .... |.|| ||| ..| .|. |.|. ||| |.. .
Mitglied im XING

Beitrag von Bitfummler (Specialist / 111 / 4 / 3 ) » 01.03.2005 08:56
ereglam hat geschrieben:nun, mir ist wohl beim Aufschreiben des Grundgerüsts (aus dem Kopf) ein Fehler unterlaufen: in den Subqueries muss zwischen dem SELECT und FORM ein '*' oder ein einzelnes Feld eingefügt werden.

Andererseits hätte ein Blick in die Hilfe helfen können, da ich nur ein Grundgerüst und nicht die vollständige Lösung liefern wollte...
Himmel JA!! wie blöd von mir... ich habe als das select der mara im auge gehabt und deswegen bin ich auch mit der hilfe nicht weiter gekommen.. :?

trotzdem danke. hat mir weitergeholfen.

Beitrag von ereglam (Top Expert / 1826 / 0 / 5 ) » 01.03.2005 09:30
Bitfummler hat geschrieben:...
Himmel JA!! wie blöd von mir... ich habe als das select der mara im auge gehabt und deswegen bin ich auch mit der hilfe nicht weiter gekommen.. :?
...
ging mir zu Anfang auch so. Habe dann aber durch Herausnahme von Teilen schnell gemerkt, welcher Teil denn den Fehler produzierte... :roll:

PS:
SELECT-ENDSELECT-Schleifen solltest Du Dir garnicht erst angewöhnen. Benutze 'INTO CORRESPONDING FIELDS OF >int. tabelle<' mit anschließendem LOOP...

Beitrag von Haubi (Expert / 608 / 13 / 27 ) » 02.03.2005 13:00
@Bitfummler: die Performance sollte immer noch gut sein, da die Subqueries auf den Primärschlüssel der MARC gehen. Intern wird das in einen INNER JOIN umgewandelt AFAIK.

@ereglam:
SELECT-ENDSELECT-Schleifen solltest Du Dir garnicht erst angewöhnen. Benutze 'INTO CORRESPONDING FIELDS OF >int. tabelle<' mit anschließendem LOOP
Ist so nicht richtig. Das SELECT/ENDSELECT-Konstrukt bewirkt genau wie ein INTO TABLE einen blockweisen Datentransport, beide Varianten sind also gleich schnell.
Netto verlierst Du also sogar Performance, wenn Du die Daten nur holst und einmalig in einem LOOP verarbeitest.
Benötigst Du die Daten allerdings später noch einmal gewinnt wieder die "INTO TABLE/LOOP"-Variante.

Gruss,
Haubi
Das ABAP Kochbuch ab sofort bei Amazon...

I'd rather write code that writes code than write code...

Beitrag von Bitfummler (Specialist / 111 / 4 / 3 ) » 02.03.2005 14:10
ereglam hat geschrieben:
Bitfummler hat geschrieben:...
Himmel JA!! wie blöd von mir... ich habe als das select der mara im auge gehabt und deswegen bin ich auch mit der hilfe nicht weiter gekommen.. :?
...
ging mir zu Anfang auch so. Habe dann aber durch Herausnahme von Teilen schnell gemerkt, welcher Teil denn den Fehler produzierte... :roll:

PS:
SELECT-ENDSELECT-Schleifen solltest Du Dir garnicht erst angewöhnen. Benutze 'INTO CORRESPONDING FIELDS OF >int. tabelle<' mit anschließendem LOOP...
naja, so ganz am anfang bin ich nicht mehr.. derartige selects verwende ich eh seltenstens.
das war noch bei db2-programmierung mit pl1.. diese anforderung kam von kollegen. ich lese auch fast ausschliesslich in interne tabellen und vermampel dann diese. da bin ich ganz deiner meinung! :P

Beitrag von Bitfummler (Specialist / 111 / 4 / 3 ) » 02.03.2005 14:15
Haubi hat geschrieben:@Bitfummler: die Performance sollte immer noch gut sein, da die Subqueries auf den Primärschlüssel der MARC gehen. Intern wird das in einen INNER JOIN umgewandelt AFAIK.

@ereglam:
SELECT-ENDSELECT-Schleifen solltest Du Dir garnicht erst angewöhnen. Benutze 'INTO CORRESPONDING FIELDS OF >int. tabelle<' mit anschließendem LOOP
Ist so nicht richtig. Das SELECT/ENDSELECT-Konstrukt bewirkt genau wie ein INTO TABLE einen blockweisen Datentransport, beide Varianten sind also gleich schnell.
Netto verlierst Du also sogar Performance, wenn Du die Daten nur holst und einmalig in einem LOOP verarbeitest.
Benötigst Du die Daten allerdings später noch einmal gewinnt wieder die "INTO TABLE/LOOP"-Variante.

Gruss,
Haubi
hallo haubi,

nach meinen infos ist es performanter, ueber eine int. tabelle zu loopen, als mit select endselect
(zumindestens lt. unserem db2-guru). ich denke, es kommt auch immer auf die datenmengen an. bei riesigen datenmengen stimme ich wiederum dir zu. da platzt leicht mal eine tabelle oder paralell laufende programme rauben sich gegenseitig den speicher. das hatten wir hier grad aktuell.

manchmal ist es auch notwendig, dass die daten sortiert verarbeitet werden sollen. das ist toedlich bei select endselect! performance-killer pur!

Gruss
Bitfummler

Beitrag von Haubi (Expert / 608 / 13 / 27 ) » 02.03.2005 14:17
Da gilt wieder genau das, was immer gilt, wenn es um Performance geht: It depends... :wink: :D
Das ABAP Kochbuch ab sofort bei Amazon...

I'd rather write code that writes code than write code...

Beitrag von ereglam (Top Expert / 1826 / 0 / 5 ) » 02.03.2005 15:21
Bitfummler hat geschrieben:
ereglam hat geschrieben:...ging mir zu Anfang auch so. ...
damit war gemeint:
als ich mir den Code anschaute und im Editor checken ließ, habe ich zu Anfang auch übersehen, dass dieser SELECT ja 3 FROM beinhaltete...

PS:
solche Konstrukte sind bei mir auch eher selten... ;)
Haubi hat geschrieben:Da gilt wieder genau das, was immer gilt, wenn es um Performance geht: It depends... :wink: :D
die MARA im Produktivsystem würde ich auch eher selten komplett in eine interne Tabelle laden wollen. Für so etwas gibt es ja dann noch die OPEN CURSOR... FETCH mit blockweisem Bearbeiten der Ergebnismenge...

Wie auch Bitfummler schon ausgeführt hat, sind die SAP-Basis-Leute von SELECT-Schleifen nicht erfreut, zumal mal beim Debuggen auch immer wieder Probleme mit dem systemseitigen COMMIT WORK gibt.
Außerdem kann mir keiner erzählen, dass ein LOOP langsamer sei als ein SELECT. Lediglich unter der Berücksichtigung der Ladezeit der Tabelle dürften kurze Tabellen insgesamt langsamer sein.
Gruß
Ereglam


May the Force be with your code
|| .| |.|| | .... . ..|. ||| .|. |.|. . |... . .|| .. | .... |.|| ||| ..| .|. |.|. ||| |.. .
Mitglied im XING

Beitrag von Haubi (Expert / 608 / 13 / 27 ) » 02.03.2005 15:52
ereglam hat geschrieben:
Haubi hat geschrieben:Da gilt wieder genau das, was immer gilt, wenn es um Performance geht: It depends... :wink: :D
die MARA im Produktivsystem würde ich auch eher selten komplett in eine interne Tabelle laden wollen. Für so etwas gibt es ja dann noch die OPEN CURSOR... FETCH mit blockweisem Bearbeiten der Ergebnismenge...
...oder den SELECT...PACKAGE-SIZE.
Außerdem kann mir keiner erzählen, dass ein LOOP langsamer sei als ein SELECT. Lediglich unter der Berücksichtigung der Ladezeit der Tabelle dürften kurze Tabellen insgesamt langsamer sein.
Wenn es nur darum geht, eine Tabelle auszulesen und die ausgelesenen Sätze zu verarbeiten (z.B. klassische Listverarbeitung) ist der SELECT...ENDSELECT überlegen.
In jeder anderen Konstellation gewinnt der INTO TABLE.

Gruss,
Haubi
Das ABAP Kochbuch ab sofort bei Amazon...

I'd rather write code that writes code than write code...

Beitrag von black_adept (Top Expert / 3377 / 65 / 634 ) » 02.03.2005 17:22
Um nochmal auf das ursprüngliche Posting zurückzukommen. Die Lösung von ereglam mit den Subqueries gefällt mir hier gar nicht, da ja nach einem "unkomplizierten" Lösung gesucht wurde. Und die Fragestellung an sich schreit doch nach einem doppelten Join.

Code: Alles auswählen.

select >felder<
    into corresponding fields of table t_matnr
    from mara join marc as m1 on m1~matnr = mara~matnr
              join marc as m2 on m2~matnr = mara~matnr
    where m1~werks = >werk1<
      and m2~werks = >werk2<.
Und auf dem System das ich hier habe ( mit mäßig gefüllten MARA (70.000) und MARC (200.000 )) ist der "einfache" Join ca. doppelt so schnell wie der Subquery.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de


Über diesen Beitrag


Unterstütze die Community und teile den Beitrag für mehr Leser und besseren Inhalt:

Vergleichbare Themen

MARA und MARC - Unterschied?
von genua » 25.10.2007 18:40
Anzahl Tabelleneinträge
von sandrabudni » 25.10.2006 15:24
Zeitabhängige Tabelleneinträge
von ewx » 07.04.2011 11:08
Tabelleneinträge als Objekte verwalten
von ralf.wenzel » 17.05.2014 09:49