Möglichkeiten um Daten aus 2 oder mehr Tabellen zu lesen

Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.

Getting started ... Alles für einen gelungenen Start.
18 Beiträge • Seite 1 von 2 (current) Nächste
18 Beiträge Seite 1 von 2 (current) Nächste

Möglichkeiten um Daten aus 2 oder mehr Tabellen zu lesen

Beitrag von Andrea F. ( / / 0 / 3 ) »
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

gesponsert
Stellenangebote auf ABAPforum.com schalten
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.

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
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.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Beitrag von Andrea F. ( / / 0 / 3 ) »
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

Beitrag von Haubi (Expert / 625 / 20 / 30 ) »
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
Das ABAP Kochbuch ab sofort bei Amazon...

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

Beitrag von TakerOne (Specialist / 102 / 0 / 3 ) »
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
Ich bin eigentlich ein sehr netter Mensch.
Wenn ich Freunde hätte, könnten diese es bestätigen. :-)

Beitrag von Andrea F. ( / / 0 / 3 ) »
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

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
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.
TakerOne hat geschrieben:Ein Join macht nur Sinn, wenn er sehr klein und überschaubar ist, alles andere ist von Übel.
Grund?
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.
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.
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...

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.
Polemie ist keine gut Basis für einen Beweis.
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.
TakerOne hat geschrieben: Als Programmierer alter Schule (25 Jahre),bestimme ICH, was, wann und wie gelesen wird, nicht die Optimierungsroutine der Datenbank.
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.
Hauptsache ist doch, dass das Programm korrekt, hinreichend schnell und gut lesbar ist.
TakerOne hat geschrieben:Als langjähriger, festangestellter Programmierer weiß ich aus bitterer Erfahrung mit den "Ausserirdischen" worüber ich spreche.
Glücklicherweise bin ich bisher solchen xenophopischen Ansichten nicht begegnet.

TakerOne hat geschrieben:Die Ausführungen sind zwar etwas provokant, aber ehrlich.
Meine sind auch ehrlich - aber hoffentlich nicht so provokant...
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
Andrea F. hat geschrieben:... Inner Join ist je nachdem unübersichtlich ..
Unfug.
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... :?
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Beitrag von Gast ( / / 0 / 3 ) »
black_adept hat geschrieben:Ein JOIN ist nicht unübersichtlicher als ein SELECT.
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, ...
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 / 3943 / 105 / 886 ) »
@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.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

join oder select

Beitrag von GAST ( / / 0 / 3 ) »
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

Beitrag von Gast ( / / 0 / 3 ) »
Hi BlackAdept,

deine Kritik trifft mich aber tief und hart. :cry:

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.
Diese Programme zu lesen, ist ja kein Problem, wenn man einen ordentlichen Bildschirm oder guten Drucker hat. Das Problem ist selbige zu verstehen. :lol:
Gehört halt zum proggen dazu, dass man weiß was so ein JOIN macht ( oder machen soll ) und wie man im Fehlerfall hier debuggt...
Ich weiß was er machen soll, du weißt was er machen soll, macht er aber wirklich das was er soll? :lol:
Ganz im Vertrauen - ich kann sowohl einen SELECT als auch einen JOIN entweder übersichtlich oder unübersichtlich schreiben.
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. :lol:
Glücklicherweise bin ich bisher solchen xenophopischen Ansichten nicht begegnet.
Als alter Trecki der ersten Stunde habe ich nun mal solche Ansichten. :lol:


Meine Meinung war natürlich nicht sooo ernst gemeint, aber sollte doch nur die Diskussion anregen.

Und? Es hat geklappt.


Gruß TakerOne

Beitrag von DON_ABAP ( / / 0 / 3 ) »
Ich weiß was er machen soll, du weißt was er machen soll, macht er aber wirklich das was er soll?
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.

Unbestreitbar ist, dass der Join wesentlich schneller ist als ein geschachelter Select. Und der Endanwender erwartet schnelle Antwortzeiten.

Beitrag von Haubi (Expert / 625 / 20 / 30 ) »
DON_ABAP hat geschrieben:
Ich weiß was er machen soll, du weißt was er machen soll, macht er aber wirklich das was er soll?
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.
Es gibt ein Verfahren, das "Unit-Test" genannt wird und dem Zweck dient, die Funktionalität kleinstmöglicher Codestrecken zu überprüfen... :lol:
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.
Unbestreitbar ist, dass der Join wesentlich schneller ist als ein geschachelter Select. Und der Endanwender erwartet schnelle Antwortzeiten.
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.
Das ABAP Kochbuch ab sofort bei Amazon...

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

Vergleichbare Themen

4
Antw.
1799
Views
Tägliche Ablage von Daten -> Möglichkeiten zur Architektu
von Chris2000 » 23.04.2005 14:53 • Verfasst in ABAP® für Anfänger
9
Antw.
4743
Views
Daten aus 2 Tabellen + Vergleich von Daten
von dv88 » 06.10.2009 12:26 • Verfasst in ABAP® für Anfänger
3
Antw.
159
Views
Daten aus Struktur lesen
von Maggonski » 08.02.2023 10:31 • Verfasst in ABAP® für Anfänger
1
Antw.
5306
Views
Daten aus SQL-Server lesen
von Willi » 27.01.2006 09:10 • Verfasst in Exchange Infrastructure
3
Antw.
7788
Views
Tabellen per RFC lesen
von Foppa » 10.03.2010 16:56 • Verfasst in ABAP® Core

Ü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

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 71
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 111
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 141