SQL JOINS
14 Beiträge
•
Seite 1 von 1
14 Beiträge
Seite 1 von 1
Hello,
bei einem left join dürfen ja keine Felder aus der rechten Tabelle in die WHERE Bedingung mitgenommen werden.
Wenn ich jetzt mehrere Tabellen joinen möchte und ich habe einen SELECT-OPTIONS
mit dem das Ergebnis noch eingeschränkt werden kann. Wie mache ich das am besten?
Beispiel:
Natürlich kann ich SCARR und SPFLI jetzt umtauschen. Angenommen man könnte es nicht oder man hat viele verschiedene Tabellen usw..
bei einem left join dürfen ja keine Felder aus der rechten Tabelle in die WHERE Bedingung mitgenommen werden.
Wenn ich jetzt mehrere Tabellen joinen möchte und ich habe einen SELECT-OPTIONS
mit dem das Ergebnis noch eingeschränkt werden kann. Wie mache ich das am besten?
Beispiel:
Code: Alles auswählen.
SELECT-OPTIONS: s_carrn FOR ls_scarr-carrname.
SELECT a~CARRID, a~CONNID, b~CURRENCY
c~CARRNAME
FROM SPFLI as a
LEFT JOIN SFLIGHT as b
ON a~carrid = b~carrid
AND a~connid = b~connid
LEFT JOIN SCARR as c
ON a~carrid = c~carrid
INTO TABLE @DATA(itab)
WHERE " hier am besten CARRNAME IN @s_carrn, das wäre das beste, darf ja nicht gemacht werden
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
Hi.
Ab Basis 7.50 ist es möglich auch die rechte Seite in einem left outer join abzufragen.
Zu bechaten ist nur das spezielle Verhalten in diesem Fall in Zusammenspiel mit dem IN Operator. Wenn die Range-Tabelle (Select-option) leer ist, gibt es keine Probleme, weil dann die Bedingung sowieso ignoriert wird. Wenn man aber zusammen mit Werten von beiden Seiten des Joins auch jene haben möchte die auf der rechten Seite nicht vorhanden (NULL) sind, wird es etwas tricky. Da ABAP grundsätzlich kein NULL in der internen Verarbeitung kennt, muss man die Abfrage dann etwas anders formulieren:
Wenn der Benutzer die Abfrage auf NULL z.B. mit einem eigenen Leereintrag (SIGN = 'I' OPTION = 'EQ' LOW = '') steuern können soll, dann muss man das mit zwei getrennten SELECTs machen:
lg ADT
Ab Basis 7.50 ist es möglich auch die rechte Seite in einem left outer join abzufragen.
Zu bechaten ist nur das spezielle Verhalten in diesem Fall in Zusammenspiel mit dem IN Operator. Wenn die Range-Tabelle (Select-option) leer ist, gibt es keine Probleme, weil dann die Bedingung sowieso ignoriert wird. Wenn man aber zusammen mit Werten von beiden Seiten des Joins auch jene haben möchte die auf der rechten Seite nicht vorhanden (NULL) sind, wird es etwas tricky. Da ABAP grundsätzlich kein NULL in der internen Verarbeitung kennt, muss man die Abfrage dann etwas anders formulieren:
Code: Alles auswählen.
SELECT-OPTIONS: s_carrn FOR ls_scarr-carrname.
SELECT a~CARRID, a~CONNID, b~CURRENCY
c~CARRNAME
FROM SPFLI as a
LEFT JOIN SFLIGHT as b
ON a~carrid = b~carrid
AND a~connid = b~connid
LEFT JOIN SCARR as c
ON a~carrid = c~carrid
INTO TABLE @DATA(itab)
WHERE c~carrname IN @s_carrn OR c~carrname IS NULL.Code: Alles auswählen.
IF space IN s_carrn[].
SELECT a~CARRID, a~CONNID, b~CURRENCY
c~CARRNAME
FROM SPFLI as a
LEFT JOIN SFLIGHT as b
ON a~carrid = b~carrid
AND a~connid = b~connid
LEFT JOIN SCARR as c
ON a~carrid = c~carrid
INTO TABLE @DATA(itab)
WHERE c~carrname IN @s_carrn OR c~carrname IS NULL.
ELSE.
SELECT a~CARRID, a~CONNID, b~CURRENCY
c~CARRNAME
FROM SPFLI as a
LEFT JOIN SFLIGHT as b
ON a~carrid = b~carrid
AND a~connid = b~connid
LEFT JOIN SCARR as c
ON a~carrid = c~carrid
INTO TABLE @DATA(itab)
WHERE c~carrname IN @s_carrn.
ENDIF.Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
ABAPlerv
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Das behebt evtl. der COALESCE-Befehl?a-dead-trousers hat geschrieben: ↑18.05.2022 21:36Wenn der Benutzer die Abfrage auf NULL z.B. mit einem eigenen Leereintrag (SIGN = 'I' OPTION = 'EQ' LOW = '') steuern können soll, dann muss man das mit zwei getrennten SELECTs machen:
Bin mir nicht sicher, ob das auch bei deinem Beispiel helfen würde...
Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
a-dead-trousers
a-dead-trousers hat geschrieben: ↑18.05.2022 21:36Hi.
Ab Basis 7.50 ist es möglich auch die rechte Seite in einem left outer join abzufragen.
Zu bechaten ist nur das spezielle Verhalten in diesem Fall in Zusammenspiel mit dem IN Operator. Wenn die Range-Tabelle (Select-option) leer ist, gibt es keine Probleme, weil dann die Bedingung sowieso ignoriert wird. Wenn man aber zusammen mit Werten von beiden Seiten des Joins auch jene haben möchte die auf der rechten Seite nicht vorhanden (NULL) sind, wird es etwas tricky. Da ABAP grundsätzlich kein NULL in der internen Verarbeitung kennt, muss man die Abfrage dann etwas anders formulieren:Wenn der Benutzer die Abfrage auf NULL z.B. mit einem eigenen Leereintrag (SIGN = 'I' OPTION = 'EQ' LOW = '') steuern können soll, dann muss man das mit zwei getrennten SELECTs machen:Code: Alles auswählen.
SELECT-OPTIONS: s_carrn FOR ls_scarr-carrname. SELECT a~CARRID, a~CONNID, b~CURRENCY c~CARRNAME FROM SPFLI as a LEFT JOIN SFLIGHT as b ON a~carrid = b~carrid AND a~connid = b~connid LEFT JOIN SCARR as c ON a~carrid = c~carrid INTO TABLE @DATA(itab) WHERE c~carrname IN @s_carrn OR c~carrname IS NULL.lg ADTCode: Alles auswählen.
IF space IN s_carrn[]. SELECT a~CARRID, a~CONNID, b~CURRENCY c~CARRNAME FROM SPFLI as a LEFT JOIN SFLIGHT as b ON a~carrid = b~carrid AND a~connid = b~connid LEFT JOIN SCARR as c ON a~carrid = c~carrid INTO TABLE @DATA(itab) WHERE c~carrname IN @s_carrn OR c~carrname IS NULL. ELSE. SELECT a~CARRID, a~CONNID, b~CURRENCY c~CARRNAME FROM SPFLI as a LEFT JOIN SFLIGHT as b ON a~carrid = b~carrid AND a~connid = b~connid LEFT JOIN SCARR as c ON a~carrid = c~carrid INTO TABLE @DATA(itab) WHERE c~carrname IN @s_carrn. ENDIF.
Danke. das erleichtert alles um einiges.
Wenn s_carrn ein einzelner Werte wäre zum Beispiel 'Lufthansa', könnte man doch auch im ON Bedingung schreiben oder?
Code: Alles auswählen.
select ....
...
..
..
LEFT JOIN SCARR as c
ON c~carrname = @'Lufthansa'....
Beitrag
von black_adept (Top Expert / 4093 / 128 /
940
)
»
Moin ABAPlerv,
Aber du hast ja explizit den "ANGENOMMEN..." Fall angesprochen. Angenommen du hättest die Selopt auf ein NichtSchlüsselfeld der rechten Tabelle gemacht.
Hier kann man eine ähnliche Überlegung anstellen, wie sie schon a-d-t für den 7.5x-Fell erklärt hat.
Falls mind. eine der SelOpts, die auf die rechte Tabelle des Right-Joins abzielen, eine Bedingung enthält ( die SPACE = NULL-Geschichte lassen wir hier mal unter der Tisch fallen - das ist ein Spezialthema ), möchte der User ja explizit auf die rechte Tabelle selektieren. In diesem Fall kannst du den RIGHT-JOIN in einen LEFT-JOIN umwandeln und hast dann kein Problem mehr mit dem Platzieren der Bedingungen der rechten Tabelle.
Wenn hingegen keine einzige Selopt für die rechte Tabelle eine Bedingung enthält, kannst du den RIGHT-JOIN so stehen lassen, brauchst aber die SELOPTs nicht verwenden.
Somit ist eine einfache Fallunterscheidung die Lösung deines Problems.
Nachtrag: Wenn du dem User wie bei a-d-t die "NULL = SPACE" Selektion erlauben willst musst du vor 7.5x für die Selektionsoptionen, welche ein "SPACE" in der Ergebnismenge erlauben statt des "IS NULL" ein "NOT EXISTS-Subselect" abesetzen, was eine nervige Schreibarbeit ist, wenn du mehrere solcher Selopts bereit stellst.
Nachtrag2: Wenn du viele Selopts auf vielen (verschiedenen) RIGHT-JOINS hast wird das wirklich nervig und die Anzahl der Fallunterscheidungen meist so groß, dass man hier letztlich nur sinnvoll weiterkommt, wenn man mit dynamischen Bedingungen sowohl im FROM als auch im WHERE -Part um sich wirft. Das ist aber nicht sonderlich toll zu lesen oder zu debuggen und sehr! fehleranfällig. Und in meiner Erfahrung ist es dann häufig so, dass in so einem Fall entweder am Datenmodell oder an den Useranforderungen etwas nicht ganz i.O. ist oder implizit die SPACE=NULL Regel von der Usern gewünscht wird. Beispiel: "Wir wollen alle Aufträge sehen mit Bedingungen ... und wenn schon eine Faktura dazu existiert, dann nur die, die auch die Bedingung ... erfüllen", wo durch das "und wenn schon... existiert" die SPACE=NULL Bedingung implizit heraufbeschworen wurde. Und in so einem Fall versuche ich dann tatsächlich über Fallunterscheidung zu gehen, weil das viel besser dokumentier- und wartbar bleibt.
Das klappt nicht, weil damit SPFLI über den CARRID-Schlüssel nicht mehr korrekt mit der SCARR gejoint wird. ( Du erhältst jetzt Treffer, die Werte <> "Lufthansa" in SPFLI-CARRID enthalten ).ABAPlerv hat geschrieben: ↑19.05.2022 11:29Wenn s_carrn ein einzelner Werte wäre zum Beispiel 'Lufthansa', könnte man doch auch im ON Bedingung schreiben oder?
Code: Alles auswählen.
select .... ... .. .. LEFT JOIN SCARR as c ON c~carrname = @'Lufthansa'....
Zunächst einmal muss man festhalten, dass in deinem Fall CARRID ein Schlüsselfeld von SCARR ist und weiterhin in der JOIN-Bedingung auftaucht. Wenn du von der Konsistenz der Daten im Rahmen des Flugdatenmodells ausgehst sollte somit niemals ein Datensatz existieren, bei dem die Bedingung fehlschlägt, so dass du eigentlich auch gleich einen LEFT JOIN verwenden kannst und dann kannst du auch die Selopt gleich in die 1. Tabelle nach vorne ziehen, wo CARRID angesprochen wird und die SCARR wird lediglich zum weiteren Datenfüllen verwendet.
Aber du hast ja explizit den "ANGENOMMEN..." Fall angesprochen. Angenommen du hättest die Selopt auf ein NichtSchlüsselfeld der rechten Tabelle gemacht.
Hier kann man eine ähnliche Überlegung anstellen, wie sie schon a-d-t für den 7.5x-Fell erklärt hat.
Falls mind. eine der SelOpts, die auf die rechte Tabelle des Right-Joins abzielen, eine Bedingung enthält ( die SPACE = NULL-Geschichte lassen wir hier mal unter der Tisch fallen - das ist ein Spezialthema ), möchte der User ja explizit auf die rechte Tabelle selektieren. In diesem Fall kannst du den RIGHT-JOIN in einen LEFT-JOIN umwandeln und hast dann kein Problem mehr mit dem Platzieren der Bedingungen der rechten Tabelle.
Wenn hingegen keine einzige Selopt für die rechte Tabelle eine Bedingung enthält, kannst du den RIGHT-JOIN so stehen lassen, brauchst aber die SELOPTs nicht verwenden.
Somit ist eine einfache Fallunterscheidung die Lösung deines Problems.
Nachtrag: Wenn du dem User wie bei a-d-t die "NULL = SPACE" Selektion erlauben willst musst du vor 7.5x für die Selektionsoptionen, welche ein "SPACE" in der Ergebnismenge erlauben statt des "IS NULL" ein "NOT EXISTS-Subselect" abesetzen, was eine nervige Schreibarbeit ist, wenn du mehrere solcher Selopts bereit stellst.
Nachtrag2: Wenn du viele Selopts auf vielen (verschiedenen) RIGHT-JOINS hast wird das wirklich nervig und die Anzahl der Fallunterscheidungen meist so groß, dass man hier letztlich nur sinnvoll weiterkommt, wenn man mit dynamischen Bedingungen sowohl im FROM als auch im WHERE -Part um sich wirft. Das ist aber nicht sonderlich toll zu lesen oder zu debuggen und sehr! fehleranfällig. Und in meiner Erfahrung ist es dann häufig so, dass in so einem Fall entweder am Datenmodell oder an den Useranforderungen etwas nicht ganz i.O. ist oder implizit die SPACE=NULL Regel von der Usern gewünscht wird. Beispiel: "Wir wollen alle Aufträge sehen mit Bedingungen ... und wenn schon eine Faktura dazu existiert, dann nur die, die auch die Bedingung ... erfüllen", wo durch das "und wenn schon... existiert" die SPACE=NULL Bedingung implizit heraufbeschworen wurde. Und in so einem Fall versuche ich dann tatsächlich über Fallunterscheidung zu gehen, weil das viel besser dokumentier- und wartbar bleibt.
a-dead-trousers hat geschrieben: ↑18.05.2022 21:36Hi.
Ab Basis 7.50 ist es möglich auch die rechte Seite in einem left outer join abzufragen.
Zu bechaten ist nur das spezielle Verhalten in diesem Fall in Zusammenspiel mit dem IN Operator. Wenn die Range-Tabelle (Select-option) leer ist, gibt es keine Probleme, weil dann die Bedingung sowieso ignoriert wird. Wenn man aber zusammen mit Werten von beiden Seiten des Joins auch jene haben möchte die auf der rechten Seite nicht vorhanden (NULL) sind, wird es etwas tricky. Da ABAP grundsätzlich kein NULL in der internen Verarbeitung kennt, muss man die Abfrage dann etwas anders formulieren:Wenn der Benutzer die Abfrage auf NULL z.B. mit einem eigenen Leereintrag (SIGN = 'I' OPTION = 'EQ' LOW = '') steuern können soll, dann muss man das mit zwei getrennten SELECTs machen:Code: Alles auswählen.
SELECT-OPTIONS: s_carrn FOR ls_scarr-carrname. SELECT a~CARRID, a~CONNID, b~CURRENCY c~CARRNAME FROM SPFLI as a LEFT JOIN SFLIGHT as b ON a~carrid = b~carrid AND a~connid = b~connid LEFT JOIN SCARR as c ON a~carrid = c~carrid INTO TABLE @DATA(itab) WHERE c~carrname IN @s_carrn OR c~carrname IS NULL.lg ADTCode: Alles auswählen.
IF space IN s_carrn[]. SELECT a~CARRID, a~CONNID, b~CURRENCY c~CARRNAME FROM SPFLI as a LEFT JOIN SFLIGHT as b ON a~carrid = b~carrid AND a~connid = b~connid LEFT JOIN SCARR as c ON a~carrid = c~carrid INTO TABLE @DATA(itab) WHERE c~carrname IN @s_carrn OR c~carrname IS NULL. ELSE. SELECT a~CARRID, a~CONNID, b~CURRENCY c~CARRNAME FROM SPFLI as a LEFT JOIN SFLIGHT as b ON a~carrid = b~carrid AND a~connid = b~connid LEFT JOIN SCARR as c ON a~carrid = c~carrid INTO TABLE @DATA(itab) WHERE c~carrname IN @s_carrn. ENDIF.
Hallo,
Mir ist das noch immer etwas unklar.
Also es ist nun möglich die rechte Tabelle in der WHERE Bedingung zu fragen.
Was mir unklar ist, wann könnte es Probleme geben und wie umgeht man die Probleme?
Was wäre noch eine Möglichkeit die rechte Tabelle einzuschränken? In einem separaten Loop?
Kann ich ohne Bedenken immer für die rechte Tabelle verwenden:
Code: Alles auswählen.
SELECT-OPTIONS: s_carrn FOR ls_scarr-carrname.
SELECT a~CARRID, a~CONNID, b~CURRENCY
c~CARRNAME
FROM SPFLI as a
LEFT JOIN SFLIGHT as b
ON a~carrid = b~carrid
AND a~connid = b~connid
LEFT JOIN SCARR as c
ON a~carrid = c~carrid
INTO TABLE @DATA(itab)
WHERE c~carrname IN @s_carrn OR c~carrname IS NULL.
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
Das Problem ist, wenn auf der "rechten Seite" des JOIN nichts vorhanden ist. Dann sind alls Felder auf NULL zu prüfen, wenn du von der "linken Seite" trotzdem etwas haben möchtest.
Hier kommt nun eine Spezialität von ABAP zum Zug. Weil ABAP kein NULL kennt werden alle Felder der "rechten Tabelle" im Ergebnis als "leer" oder "initial" befüllt. (CHAR => space, INT => 0, usw.). Daher verhällt sich der LOOP anders als die Abfrage direkt im SELECT.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Hallo, ich bin gerade etwas verwirrt mit multiple joins..
Ein Join sind klar:
- Tabelle A left Join B = man selektiert alle Zeilen von A ( auch mehrfach, wenn der A weniger Key Felder hat als B)
- Tabelle A INNER JOIN B = man selektiert alle Zeilen, wo die Daten bei A UND B bezüglich ON Bedingung gleich ist
2 oder mehrfache joins:
1. Fall: hier werden alle Zeilen von A selektiert. B und C werden dazugelesen, nach dem 2. left Join kann es mehr Zeilen geben als nach dem ersten JOIN , aber nicht weniger
2.Fall:
Hier habe ich ein Problem: alle Zeilen von A werden selektiert, klar! Was ist jetzt mit dem 2. JOIN? Werden hier alle Zeilen B selektiert unabhängig von dem ersten JOIN? Oder werden im 2. Join alle Zeilen von B betrachtet, die im ersten JOIN "hinzugefügt" worden sind?
3. Fall:
Werden hier nach dem 2.join Zeilen von A vernichtet, wenn die Bedingung im 2. Join nicht passt? Zuerst werden alle Zeilen selektiert von A und dann mit C inner gejoined, sodass Zeilen vernichtet werden.
4. Fall:
Werden hier Zeilen von B nach dem ersten LEFT JOIN vernichtet, wenn B und C nicht passen, obwohl nach dem ersten JOIN sie eventuell dazu selektiert worden wären?
5.Fall:
Als erstes werden Zeilen werden selektiert, wo A und B passen,
Und dann wo A und C passen. Nach dem ersten Join könnte es mehr Daten geben und im 2. werden eventuell Daten wieder vernichtet.
Ich bitte euch hier um eine Klarstellung
Danke euch!
Ein Join sind klar:
- Tabelle A left Join B = man selektiert alle Zeilen von A ( auch mehrfach, wenn der A weniger Key Felder hat als B)
- Tabelle A INNER JOIN B = man selektiert alle Zeilen, wo die Daten bei A UND B bezüglich ON Bedingung gleich ist
2 oder mehrfache joins:
1. Fall:
Code: Alles auswählen.
select " Felder...
FROM A LEFT JOIN B
On .......
LEFT JOIN C
On A~ = C~ 2.Fall:
Code: Alles auswählen.
select " Felder...
FROM A LEFT JOIN B
On .......
LEFT JOIN C
On B~ = C~ Hier habe ich ein Problem: alle Zeilen von A werden selektiert, klar! Was ist jetzt mit dem 2. JOIN? Werden hier alle Zeilen B selektiert unabhängig von dem ersten JOIN? Oder werden im 2. Join alle Zeilen von B betrachtet, die im ersten JOIN "hinzugefügt" worden sind?
3. Fall:
Code: Alles auswählen.
select " Felder...
FROM A LEFT JOIN B
On .......
INNER JOIN C
On A~ = C~ Werden hier nach dem 2.join Zeilen von A vernichtet, wenn die Bedingung im 2. Join nicht passt? Zuerst werden alle Zeilen selektiert von A und dann mit C inner gejoined, sodass Zeilen vernichtet werden.
4. Fall:
Code: Alles auswählen.
select " Felder...
FROM A LEFT JOIN B
On .......
INNER JOIN C
On B~ = C~ Werden hier Zeilen von B nach dem ersten LEFT JOIN vernichtet, wenn B und C nicht passen, obwohl nach dem ersten JOIN sie eventuell dazu selektiert worden wären?
5.Fall:
Code: Alles auswählen.
select " Felder...
FROM A INNER JOIN B
On .......
INNER JOIN C
On A~ = C~ Als erstes werden Zeilen werden selektiert, wo A und B passen,
Und dann wo A und C passen. Nach dem ersten Join könnte es mehr Daten geben und im 2. werden eventuell Daten wieder vernichtet.
Ich bitte euch hier um eine Klarstellung
Danke euch!
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
Hi.
1.) Ja.
2.) Wenn der Join für B nichts findet wird auch für C nichts zusätzliches selektiert.
3.) Ja, der inner Join zwischen A und C "verhindert" Zeilen die nicht in beiden Tabellen vorkommen.
4.) Ja.
5.) Ja.
Es werden aber keine Daten "vernichtet". Stell dir das Konstrukt einfach als eine neue Tabelle vor in der die Zeilen aller beteiligten Tabellen darin vorkommen. In welcher Beziehung diese Zeilen zueinander stehen wird über die ON-Bedingung festgelegt.
1.) Ja.
2.) Wenn der Join für B nichts findet wird auch für C nichts zusätzliches selektiert.
3.) Ja, der inner Join zwischen A und C "verhindert" Zeilen die nicht in beiden Tabellen vorkommen.
4.) Ja.
5.) Ja.
Es werden aber keine Daten "vernichtet". Stell dir das Konstrukt einfach als eine neue Tabelle vor in der die Zeilen aller beteiligten Tabellen darin vorkommen. In welcher Beziehung diese Zeilen zueinander stehen wird über die ON-Bedingung festgelegt.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
ABAPlerv
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Danke! hat mir sehr weitergeholfen!a-dead-trousers hat geschrieben: ↑13.11.2022 12:072.) Wenn der Join für B nichts findet wird auch für C nichts zusätzliches selektiert.
Punkt ist mir nicht ganz klar.
Beim 2. JOIN (B und C) werden alle Zeilen von B betrachtet - also unabhängig von A?
Oder werden nur die Zeilen von B betrachtet, die schon von A un B betrachtet worden sind?
Darf man das überhaupt von LINKS nach rechts lesen?
ABAPlerv hat geschrieben: ↑13.11.2022 14:35Danke! hat mir sehr weitergeholfen!a-dead-trousers hat geschrieben: ↑13.11.2022 12:072.) Wenn der Join für B nichts findet wird auch für C nichts zusätzliches selektiert.
Punkt 2 ist mir nicht ganz klar.
Beim 2. JOIN (B und C) werden alle Zeilen von B betrachtet - also unabhängig von A?
Oder werden nur die Zeilen von B betrachtet, die schon von A un B betrachtet worden sind?
Darf man das überhaupt von LINKS nach rechts lesen?
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
ad 2.) Nur die Zeilen aus B die sowohl in A auch in C vorkommen werden selektiert.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Hallo,
Mir ist letztens aufgefallen nachden ich auf einer rechten Tabelle eine WHERE Klausel hatte, dass mir falsche Zeilen rausselektiert wurde.
Ich hatte mehrere joins in diesem Fall.
Ich habe das Gefühl, dass es manchmal funktioniert und manchmal auch nicht..
Nun wollte ich fragen, ob es bei CDS Views auch solche Probleme geben wird bzw ob man solche Probleme besser behandeln könnte?
Mir ist letztens aufgefallen nachden ich auf einer rechten Tabelle eine WHERE Klausel hatte, dass mir falsche Zeilen rausselektiert wurde.
Ich hatte mehrere joins in diesem Fall.
Ich habe das Gefühl, dass es manchmal funktioniert und manchmal auch nicht..
Nun wollte ich fragen, ob es bei CDS Views auch solche Probleme geben wird bzw ob man solche Probleme besser behandeln könnte?
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
Es werden genau dieselben "Probleme" auftreten. Einzger Unterschied ist, dass die CDS Views etwas mehr Funktionen bieten als der ABAP Standard. Das Verhalten der JOINs wird hier aber genau gleich sein, weil ja auch die gleiche Datenbank verwendet wird.
Es gibt zwar leichte Unterschiede in den SQL Dialekten unterschiedlicher Datenbank Hersteller aber soweit ich weiß ist das Verhalten von Joins überall identisch. Wenn man ein Fehlverhalten feststellt, dann liegt es mit an Sicherheit grenzender Wahrscheinlichkeit an einem Denkfehler beim Aufbau des Joins. Oft hilft es schon die Joins auf mehrere Views aufzuteilen um Komplexität herauszunehmen. Genau hier helfen die CDS Views ungemein, weil man viel umfangriechere Möglichkeiten für die View-Erstellung hat als im SAP DDIC. Auch kann man versuchen die Bedingungen vom WHERE in das ON zu verschieben oder umgekehrt. Manche Aufgabenstellungen lassen sich aber auch oft nur mittels Subselect lösen, das wird auch gerne übersehen.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Seite 1 von 1
Vergleichbare Themen
10
Antw.
Antw.
7188
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 18 Stunden von ralf.wenzel 104 / 10239
vor 18 Stunden von ralf.wenzel 104 / 10239
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 18 Stunden von ralf.wenzel 104 / 10239
vor 18 Stunden von ralf.wenzel 104 / 10239