Möglichkeiten um Daten aus 2 oder mehr Tabellen zu lesen
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.Guten Morgen allerseits,
ich beschäftige mich seit einiger Zeit im Selbststudium mit ABAP. Hab hier im Forum auch schon viele Tipps und Hinweise gefunden, großes Lob!
Da ich gerade wieder ein bißchen rumprobiere würde mich mal interessieren, welches die effektivste Methode ist Daten aus 2 oder mehr Tabellen zu lesen.
Ineinander geschachtelte Selects?
Getrennte Selects und ein "Read Table" im Loop der "Haupttabelle"?
Inner Join?
Im Moment arbeite ich mit den getrennten Selects und dem Read Table. Hab's mir irgendwo abgeschaut und komme damit prima zurecht. Aber vielleicht gibt's ja was "besseres"
Wo liegen die Vor- und Nachteile?
Danke und lieben Gruß, Andrea
ich beschäftige mich seit einiger Zeit im Selbststudium mit ABAP. Hab hier im Forum auch schon viele Tipps und Hinweise gefunden, großes Lob!
Da ich gerade wieder ein bißchen rumprobiere würde mich mal interessieren, welches die effektivste Methode ist Daten aus 2 oder mehr Tabellen zu lesen.
Ineinander geschachtelte Selects?
Getrennte Selects und ein "Read Table" im Loop der "Haupttabelle"?
Inner Join?
Im Moment arbeite ich mit den getrennten Selects und dem Read Table. Hab's mir irgendwo abgeschaut und komme damit prima zurecht. Aber vielleicht gibt's ja was "besseres"
Wo liegen die Vor- und Nachteile?
Danke und lieben Gruß, Andrea
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von DeathGuardian (Expert / 759 / 0 /
3
)
»
HI!
Also das beste ist, in der Regel, immer ein Join.
Weil du da am wenigsten Last auf der Datenbank und der Leitung von Server-zu-DB hast und es schön übersichtlich ist und es auch von der allgemeinen Performance am besten ist.
Es gibt aber auch Fälle, das man lieber ein Select-Loop-select_singel macht.
Also das beste ist, in der Regel, immer ein Join.
Weil du da am wenigsten Last auf der Datenbank und der Leitung von Server-zu-DB hast und es schön übersichtlich ist und es auch von der allgemeinen Performance am besten ist.
Es gibt aber auch Fälle, das man lieber ein Select-Loop-select_singel macht.
Beitrag
von black_adept (Top Expert / 4116 / 129 /
951
)
»
Hallo Andrea,
wie fast immer ist die Antwort: "Kommt drauf an".
Also - geschachtelter SELECT ist fast immer die falsche Löscung.
JOIN ist die von mir i.a. bevorzugte Lösung - aber da man u.a. Pooltabellen nicht joinen darf kann man diese nicht immer anwenden.
Die von dir bevorzugte Methode des 2-maligen Selects und dann READ ist auch gut - solange die Tabellen nicht arg groß werden. Auch ist es gut, wenn man auf die "Nebentabelle" mit einem halbwegs sinnvollen Schlüssel zugreifen kann.
Mein Tipp:
Wenn die Laufzeit ok ist halt dich an die Methode die dir am meisten zusagt.
wie fast immer ist die Antwort: "Kommt drauf an".
Also - geschachtelter SELECT ist fast immer die falsche Löscung.
JOIN ist die von mir i.a. bevorzugte Lösung - aber da man u.a. Pooltabellen nicht joinen darf kann man diese nicht immer anwenden.
Die von dir bevorzugte Methode des 2-maligen Selects und dann READ ist auch gut - solange die Tabellen nicht arg groß werden. Auch ist es gut, wenn man auf die "Nebentabelle" mit einem halbwegs sinnvollen Schlüssel zugreifen kann.
Mein Tipp:
Wenn die Laufzeit ok ist halt dich an die Methode die dir am meisten zusagt.
Hallo ihr 2,
da ich mit dem Select und READ Table bislang eigentlich gut klar komme, werd ich das dann erstmal beibehalten. Mit der JOIN-Bedingung komm ich nicht so wirklich zurecht (erschwert mir gerade am Anfang die Fehlersuche), aber ich werde das auf jeden Fall mal in einigen meiner Ansätze ausprobieren
Ich danke euch!
Lieben Gruß, Andrea
da ich mit dem Select und READ Table bislang eigentlich gut klar komme, werd ich das dann erstmal beibehalten. Mit der JOIN-Bedingung komm ich nicht so wirklich zurecht (erschwert mir gerade am Anfang die Fehlersuche), aber ich werde das auf jeden Fall mal in einigen meiner Ansätze ausprobieren
Ich danke euch!
Lieben Gruß, Andrea
Moin.
DB-Abfragen sind das A und O. Guck Dir mal folgende Seite an, da kannst Du SQL hoch und runter üben: http://sqlzoo.net/
Einiges davon funzt zwar nicht mit Open SQL, aber der Sinn und Zweck wird vielleicht klar.
Gruss,
Haubi
DB-Abfragen sind das A und O. Guck Dir mal folgende Seite an, da kannst Du SQL hoch und runter üben: http://sqlzoo.net/
Einiges davon funzt zwar nicht mit Open SQL, aber der Sinn und Zweck wird vielleicht klar.
Gruss,
Haubi
Hallo,
Meine Meinung:
Ein Join macht nur Sinn, wenn er sehr klein und überschaubar ist, alles andere ist von Übel.
Es mag ja schön und gut sein, daß der Join wunderbar funktioniert.
Aber: Falls ein solches Programm jemals geändert wird, hat der Nachfolger erhebliche Probleme nachzuvollziehen was der Vorgänger gewollt hat. Testen ob der Join auch richtig funktioniert, ist bei unbestimmten Test-Datenbestand ein reines Lotteriespiel.
Für Fremdprogrammierer, die ihre Join-Ergüsse und sonstigen Programmiertricks in Kundenprogrammen publizieren, sind zwar fähig ein lauffähiges programm zu erstellen, sind damit aber noch lange keine "richtigen" Programmierer. Denn dazu gehört, das die erstellten Programme übersichtlich, nachvollziehbar und änderungsfreundlich sind. Grosse Joins gehören sicherlich nicht zu dieser Kategorie.
Als Programmierer alter Schule (25 Jahre),bestimme ICH, was, wann und wie gelesen wird, nicht die Optimierungsroutine der Datenbank.
Als langjähriger, festangestellter Programmierer weiß ich aus bitterer Erfahrung mit den "Ausserirdischen" worüber ich spreche.
Die Ausführungen sind zwar etwas provokant, aber ehrlich.
Gruß TakerOne
Meine Meinung:
Ein Join macht nur Sinn, wenn er sehr klein und überschaubar ist, alles andere ist von Übel.
Es mag ja schön und gut sein, daß der Join wunderbar funktioniert.
Aber: Falls ein solches Programm jemals geändert wird, hat der Nachfolger erhebliche Probleme nachzuvollziehen was der Vorgänger gewollt hat. Testen ob der Join auch richtig funktioniert, ist bei unbestimmten Test-Datenbestand ein reines Lotteriespiel.
Für Fremdprogrammierer, die ihre Join-Ergüsse und sonstigen Programmiertricks in Kundenprogrammen publizieren, sind zwar fähig ein lauffähiges programm zu erstellen, sind damit aber noch lange keine "richtigen" Programmierer. Denn dazu gehört, das die erstellten Programme übersichtlich, nachvollziehbar und änderungsfreundlich sind. Grosse Joins gehören sicherlich nicht zu dieser Kategorie.
Als Programmierer alter Schule (25 Jahre),bestimme ICH, was, wann und wie gelesen wird, nicht die Optimierungsroutine der Datenbank.
Als langjähriger, festangestellter Programmierer weiß ich aus bitterer Erfahrung mit den "Ausserirdischen" worüber ich spreche.
Die Ausführungen sind zwar etwas provokant, aber ehrlich.
Gruß TakerOne
Ich bin eigentlich ein sehr netter Mensch.
Wenn ich Freunde hätte, könnten diese es bestätigen.
Wenn ich Freunde hätte, könnten diese es bestätigen.
Hallo Haubi,
die Internetseite schau ich mir gleich mal an. Vielen Dank für den Tipp!
Hallo TakerOne,
provokant muss ja nicht negativ sein
Aber erzähl doch mal, wie liest du denn die Daten in der Regel ein? Black_Adept schrieb ja, dass ein geschachteltes Select fast immer die falsche Lösung sei. Inner Join ist je nachdem unübersichtlich .. da bleibt nur nur Select und Read Table oder gibt es da noch etwas anderes?
Lieben Gruß, Andrea
die Internetseite schau ich mir gleich mal an. Vielen Dank für den Tipp!
Hallo TakerOne,
provokant muss ja nicht negativ sein
Aber erzähl doch mal, wie liest du denn die Daten in der Regel ein? Black_Adept schrieb ja, dass ein geschachteltes Select fast immer die falsche Lösung sei. Inner Join ist je nachdem unübersichtlich .. da bleibt nur nur Select und Read Table oder gibt es da noch etwas anderes?
Lieben Gruß, Andrea
Beitrag
von black_adept (Top Expert / 4116 / 129 /
951
)
»
Hallo TakerOne,
ich möchte Deine Aussage hier nicht unkommentiert lassen zumal m.E. viel zu wenig ausgeführt wird warum du zu dieser Einstellung kommst.
Was das "Testen ob der JOIN auch richtig funktioniert" angeht. Ist das irgendwie anders als "Testen ob das Programm das macht was es soll?"
Gehört halt zum proggen dazu, dass man weiß was so ein JOIN macht ( oder machen soll ) und wie man im Fehlerfall hier debuggt...
Und die Schlussfolgerung: "Externer Programmierer benutzt JOINs --> Derjenige ist kein "richtiger" Programmierer" ist für mich als Mathematiker nicht nachvollziehbar.
Ganz im Vertrauen - ich kann sowohl einen SELECT als auch einen JOIN entweder übersichtlich oder unübersichtlich schreiben. Und ich kann auch ohne JOIN programmieren. Aber ich benutze dieses Programmkonstrukt nicht um die Kunden in die Abhängigkeitsfalle zu treiben, sondern um eine Aufgabe mit den Mitteln zu lösen, die ich für angebracht halte.
Hauptsache ist doch, dass das Programm korrekt, hinreichend schnell und gut lesbar ist.
ich möchte Deine Aussage hier nicht unkommentiert lassen zumal m.E. viel zu wenig ausgeführt wird warum du zu dieser Einstellung kommst.
Grund?TakerOne hat geschrieben:Ein Join macht nur Sinn, wenn er sehr klein und überschaubar ist, alles andere ist von Übel.
Ich wüsste nicht wo da ein Problem liegt. Ich habe keine Probleme Programme von SAP, externen oder internen Entwicklern zu lesen auch wenn diese einen JOIN verwendeten. Das war zugegebenerweise nicht immer so - am Anfang war so ein JOIN für mich eine große Unbekannte. Aber nachdem man genug damit gearbeitet hat kann man diesen auch sehr gut lesen.TakerOne hat geschrieben: Es mag ja schön und gut sein, daß der Join wunderbar funktioniert.
Aber: Falls ein solches Programm jemals geändert wird, hat der Nachfolger erhebliche Probleme nachzuvollziehen was der Vorgänger gewollt hat. Testen ob der Join auch richtig funktioniert, ist bei unbestimmten Test-Datenbestand ein reines Lotteriespiel.
Was das "Testen ob der JOIN auch richtig funktioniert" angeht. Ist das irgendwie anders als "Testen ob das Programm das macht was es soll?"
Gehört halt zum proggen dazu, dass man weiß was so ein JOIN macht ( oder machen soll ) und wie man im Fehlerfall hier debuggt...
Polemie ist keine gut Basis für einen Beweis.TakerOne hat geschrieben:Für Fremdprogrammierer, die ihre Join-Ergüsse und sonstigen Programmiertricks in Kundenprogrammen publizieren, sind zwar fähig ein lauffähiges programm zu erstellen, sind damit aber noch lange keine "richtigen" Programmierer. Denn dazu gehört, das die erstellten Programme übersichtlich, nachvollziehbar und änderungsfreundlich sind. Grosse Joins gehören sicherlich nicht zu dieser Kategorie.
Und die Schlussfolgerung: "Externer Programmierer benutzt JOINs --> Derjenige ist kein "richtiger" Programmierer" ist für mich als Mathematiker nicht nachvollziehbar.
Ganz im Vertrauen - ich kann sowohl einen SELECT als auch einen JOIN entweder übersichtlich oder unübersichtlich schreiben. Und ich kann auch ohne JOIN programmieren. Aber ich benutze dieses Programmkonstrukt nicht um die Kunden in die Abhängigkeitsfalle zu treiben, sondern um eine Aufgabe mit den Mitteln zu lösen, die ich für angebracht halte.
Damit werde ich wohl zum Programmierer der "neuen Schule". Mir ist völlig egal ob die Optimierungsroutine der DB zuschlägt oder nicht. Und dass der Optimierer das Ergebnis des Lesens beeinflusst ist mir bisher noch nicht untergekommen.TakerOne hat geschrieben: Als Programmierer alter Schule (25 Jahre),bestimme ICH, was, wann und wie gelesen wird, nicht die Optimierungsroutine der Datenbank.
Hauptsache ist doch, dass das Programm korrekt, hinreichend schnell und gut lesbar ist.
Glücklicherweise bin ich bisher solchen xenophopischen Ansichten nicht begegnet.TakerOne hat geschrieben:Als langjähriger, festangestellter Programmierer weiß ich aus bitterer Erfahrung mit den "Ausserirdischen" worüber ich spreche.
Meine sind auch ehrlich - aber hoffentlich nicht so provokant...TakerOne hat geschrieben:Die Ausführungen sind zwar etwas provokant, aber ehrlich.
Beitrag
von black_adept (Top Expert / 4116 / 129 /
951
)
»
Unfug.Andrea F. hat geschrieben:... Inner Join ist je nachdem unübersichtlich ..
Ein JOIN ist nicht unübersichtlicher als ein SELECT.
Man muss eben nur wissen was da passiert.
Und wenn man selber einen JOIN schreibt kann man das so hinbekommen, dass er sehr leicht lesbar ist!
Hauptsache man versucht nicht mit "SELECT *" in dem JOIN zu arbeiten - das ist wohl der einzige Fall wo ich dem TakerOne recht gebe mit der Unübersichtlichkeit. Aber sonst...
Ich habe aber schon gesehen, dass z.B. in der JOIN-Bedingung der BUKRS vergessen wurde, in der WHERE-Klausel war die Bedingung nur für eine Tabelle angegeben, ...black_adept hat geschrieben:Ein JOIN ist nicht unübersichtlicher als ein SELECT.
Im Entwicklungssystem mit geringem Datenvolumen merkt man noch nicht unbedingt, dass da etwas schiefgeht.
Und Joins über 9 Tabellen, von denen 7 Customizing-Tabellen sind, sind *immer* eine Katastrophe.
Beitrag
von black_adept (Top Expert / 4116 / 129 /
951
)
»
@Gast:
Ein JOIN über 9 Tabellen ist sicher unübersichtlicher als ein SELECT über eine Tabelle.
Aber dass ein JOIN über 9 Tabellen /immer/ unübersichtlicher sein soll als 9 SELECTs über jeweils eine Tabelle halte ich auch für weit hergeholt.
Auch das Argument mit den Fehlern bei geringem Datenaufkommen kann ich nicht nachvollziehen. Dieses Argument gilt ja nicht nur für JOINs sondern auch für eine alternativ verwendete multiple SELECT-Logik - oder genaugenommen für das ganze Programm.
Der einzige Punkt in dem ich dir entgegenkommen würde wäre der, dass beim Auftauchen eines Fehlers das Debuggen bei mehreren SELECTs ( so sie denn jeweils in eine interne Tab. führen und keinen Kurzdump wg. Datenseletkionsunterbrechung hervorrufen ) einfacher ist.
Aber grade bei den ( zumindest bei mir üblichen ) JOINs über 2-4 Tabellen finde ich, dass die Übersichtlichkeit doch eher wächst.
Bsp: Alle Materialnummern ( und weitere Felder aus MARC und/oder MARA ) in eine itab, die mehreren Selektionsbedingungen aus MARA und MARC genügen sollen. Ich kann mir hier beim besten Willen nicht vorstellen, wie da ein Konstrukt aus mehreren SELECTs übersichtlicher sein soll als ein JOIN.
Ein JOIN über 9 Tabellen ist sicher unübersichtlicher als ein SELECT über eine Tabelle.
Aber dass ein JOIN über 9 Tabellen /immer/ unübersichtlicher sein soll als 9 SELECTs über jeweils eine Tabelle halte ich auch für weit hergeholt.
Auch das Argument mit den Fehlern bei geringem Datenaufkommen kann ich nicht nachvollziehen. Dieses Argument gilt ja nicht nur für JOINs sondern auch für eine alternativ verwendete multiple SELECT-Logik - oder genaugenommen für das ganze Programm.
Der einzige Punkt in dem ich dir entgegenkommen würde wäre der, dass beim Auftauchen eines Fehlers das Debuggen bei mehreren SELECTs ( so sie denn jeweils in eine interne Tab. führen und keinen Kurzdump wg. Datenseletkionsunterbrechung hervorrufen ) einfacher ist.
Aber grade bei den ( zumindest bei mir üblichen ) JOINs über 2-4 Tabellen finde ich, dass die Übersichtlichkeit doch eher wächst.
Bsp: Alle Materialnummern ( und weitere Felder aus MARC und/oder MARA ) in eine itab, die mehreren Selektionsbedingungen aus MARA und MARC genügen sollen. Ich kann mir hier beim besten Willen nicht vorstellen, wie da ein Konstrukt aus mehreren SELECTs übersichtlicher sein soll als ein JOIN.
joins über customizing tabellen sollte man nicht unbeding machen. beim join wird immer von der datenbank gelesen.
besser sind hier selects, da hier aus dem puffer gelesen wird.
macht das ganze etwas performanter
besser sind hier selects, da hier aus dem puffer gelesen wird.
macht das ganze etwas performanter
Hi BlackAdept,
deine Kritik trifft mich aber tief und hart.
Meine Meinung war natürlich nicht sooo ernst gemeint, aber sollte doch nur die Diskussion anregen.
Und? Es hat geklappt.
Gruß TakerOne
deine Kritik trifft mich aber tief und hart.
Diese Programme zu lesen, ist ja kein Problem, wenn man einen ordentlichen Bildschirm oder guten Drucker hat. Das Problem ist selbige zu verstehen.Ich wüsste nicht wo da ein Problem liegt. Ich habe keine Probleme Programme von SAP, externen oder internen Entwicklern zu lesen auch wenn diese einen JOIN verwendeten.
Ich weiß was er machen soll, du weißt was er machen soll, macht er aber wirklich das was er soll?Gehört halt zum proggen dazu, dass man weiß was so ein JOIN macht ( oder machen soll ) und wie man im Fehlerfall hier debuggt...
Aus meiner Erfahrung mit den "Ausserirdischen", die bei großen Firmen für größere Projekte immer in Heerscharen auftauchen, sieht es meist so aus: Drei Leute kommen, einer ist erfahren, einer hat schon mal einen Bildschirm gesehen und der Dritte soll lernen. Aber alle werden bezahlt, als wenn sie die Söhne von Bill Gates wären, Zumindestens sind die Maßanzüge in der Preisklasse.Ganz im Vertrauen - ich kann sowohl einen SELECT als auch einen JOIN entweder übersichtlich oder unübersichtlich schreiben.
Als alter Trecki der ersten Stunde habe ich nun mal solche Ansichten.Glücklicherweise bin ich bisher solchen xenophopischen Ansichten nicht begegnet.
Meine Meinung war natürlich nicht sooo ernst gemeint, aber sollte doch nur die Diskussion anregen.
Und? Es hat geklappt.
Gruß TakerOne
Ich kann gut nachvollziehen, was du damit meinst. Bei einem Join siehst du im Debugger das Endergebnis, z.B. in einer internen Tabelle sind 4 gefundene Sätze; du siehst und merkst nicht, dass es eigentlich 5 Sätze hätten sein sollen - beim Debuggen mit geschachteltem Select kann man im Debugger wenigstens nachvollziehen, warum ein Zugriff, der funktionieren sollte, nicht klappt.Ich weiß was er machen soll, du weißt was er machen soll, macht er aber wirklich das was er soll?
Unbestreitbar ist, dass der Join wesentlich schneller ist als ein geschachelter Select. Und der Endanwender erwartet schnelle Antwortzeiten.
Es gibt ein Verfahren, das "Unit-Test" genannt wird und dem Zweck dient, die Funktionalität kleinstmöglicher Codestrecken zu überprüfen...DON_ABAP hat geschrieben:Ich kann gut nachvollziehen, was du damit meinst. Bei einem Join siehst du im Debugger das Endergebnis, z.B. in einer internen Tabelle sind 4 gefundene Sätze; du siehst und merkst nicht, dass es eigentlich 5 Sätze hätten sein sollen - beim Debuggen mit geschachteltem Select kann man im Debugger wenigstens nachvollziehen, warum ein Zugriff, der funktionieren sollte, nicht klappt.Ich weiß was er machen soll, du weißt was er machen soll, macht er aber wirklich das was er soll?
Ernsthaft: wenn ich einen JOIN baue werden parallel entsprechende Testdaten aufgebaut, um das Ergebnis der DB-Abfrage überprüfen zu können. Daten aus n Tabellen zu selektieren um im Nachgang die Hälfte davon wieder wegzuwerfen ist a) unperformant und b) mindestens genau so unübersichtlich wie ein Join.
Es gibt aber tatsächlich Fälle, in denen der JOIN hinsichtlich Performance Nachteile hat, dies betrifft aber gewöhlich Outer Joins. Selten, habe ich aber schon erlebt.Unbestreitbar ist, dass der Join wesentlich schneller ist als ein geschachelter Select. Und der Endanwender erwartet schnelle Antwortzeiten.
Vergleichbare Themen
4
Antw.
Antw.
2006
Views
Views
Tägliche Ablage von Daten -> Möglichkeiten zur Architektu
von Chris2000 » 23.04.2005 14:53 • Verfasst in ABAP® für Anfänger
von Chris2000 » 23.04.2005 14:53 • Verfasst in ABAP® für Anfänger
9
Antw.
Antw.
5336
Views
Views
Daten aus 2 Tabellen + Vergleich von Daten
von dv88 » 06.10.2009 12:26 • Verfasst in ABAP® für Anfänger
von dv88 » 06.10.2009 12:26 • Verfasst in ABAP® für Anfänger
3
Antw.
Antw.
557
Views
Views
1
Antw.
Antw.
5533
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.