Inner Joins - Performance
11 Beiträge
•
Seite 1 von 1
11 Beiträge
Seite 1 von 1
Beitrag
von c0lt.seavers (ForumUser / 44 / 0 /
0
)
»
Hallo!
Hier bei uns im Unternehmen wir gar nicht mit INNER JOINS gearbeitet, nun frage ich mich ob dies so unperformant ist oder ob es an dem Nichtwissen einiger Programmierer liegt?!
Vielen Dank
c0lt
Hier bei uns im Unternehmen wir gar nicht mit INNER JOINS gearbeitet, nun frage ich mich ob dies so unperformant ist oder ob es an dem Nichtwissen einiger Programmierer liegt?!
Vielen Dank
c0lt
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von ABAP - Programmierer (ForumUser / 35 / 0 /
0
)
»
Hallo!
Ich denke mal das es ehem am 2-ten liegt.
Ohne inner-join muss man, wenn man den Key von 2 Tabellen hat auch 2 Selects machen.
Mit dem Inner-Join kannst du gleich 2,3, oder mehr Tabellen selektieren und schneller ist es auch noch.
Ganz nützlich ist auch die Alias-Funktion, denn dann musst du nicht immer den ganzen Tabellennamen eingeben.
Ich würde dir also empfehlen, wenn es geht mit Joins zu arbeiten.
mfg
Ich denke mal das es ehem am 2-ten liegt.
Ohne inner-join muss man, wenn man den Key von 2 Tabellen hat auch 2 Selects machen.
Mit dem Inner-Join kannst du gleich 2,3, oder mehr Tabellen selektieren und schneller ist es auch noch.
Ganz nützlich ist auch die Alias-Funktion, denn dann musst du nicht immer den ganzen Tabellennamen eingeben.
Ich würde dir also empfehlen, wenn es geht mit Joins zu arbeiten.
mfg
Also bei einem Kunden wurden alle(!) Joins umgestellt auf einzelne Selects...
Die Datenbank hat es trotz Verwendung von Schlüsselfeldern im Join nicht geschafft, die Daten direkt zu lesen. Bei einem Join über 4 Tabellen wurde z. B. in einem Fall bei der vierten Tabelle ein Full Table Scan gemacht...
Es hat keiner rausbekommen warum...
In der Regel stimmt es aber, dass ein Join schneller ist, als mehrere Selects.
Gruß,
Enno.
Die Datenbank hat es trotz Verwendung von Schlüsselfeldern im Join nicht geschafft, die Daten direkt zu lesen. Bei einem Join über 4 Tabellen wurde z. B. in einem Fall bei der vierten Tabelle ein Full Table Scan gemacht...
Es hat keiner rausbekommen warum...
In der Regel stimmt es aber, dass ein Join schneller ist, als mehrere Selects.
Gruß,
Enno.
Der Execution plan und die Prüfung, wie aktuell di DB-Statistiken sind, sollten aber weiterhelfen.ewx hat geschrieben:Also bei einem Kunden wurden alle(!) Joins umgestellt auf einzelne Selects...
Die Datenbank hat es trotz Verwendung von Schlüsselfeldern im Join nicht geschafft, die Daten direkt zu lesen. Bei einem Join über 4 Tabellen wurde z. B. in einem Fall bei der vierten Tabelle ein Full Table Scan gemacht...
Es hat keiner rausbekommen warum...
Und nicht immer ist ein Full Table Scan schlimm.
Hallo,
1. ca 10 Jahre lang gab es im R3 keine Joins. Dennoch
war performante Programmierung möglich.
2. JOINS über mehrere Tabellen sind meiner Meinung nach nicht immer leicht zu verstehen.
3. Es gibt wenige verlässliche Untersuchungen, welcher Zugriff am schnellsten ist. Ich habe vor Jahren in einem Buch, dessen Titel ich nicht mehr weiss (nicht SAP PRESS) über Perfomance-Analysen von SAP-Datenbankzugriffen gelesen, dass sich JOINS von DB zu DB unterschiedlich verhalten. ORACLE, Informix, MS-SQl. Bei ORACLE 8.x waren sie am besten. Auch die DB-Release spielt eine Rolle. Oftmals war ein ARRAY-Zugriff (select into table ) schneller. Selbst bei gleichem Betriebsystem. gleichem Datenbank-System und gleicher Hardware und ähnlicher Anzahl Einträge kann ich mir vorstellen, dass ein Zugriff unterschiedlich schnell ist, wenn auf unterschiedliche Weise rein geschrieben wurde.
1. ca 10 Jahre lang gab es im R3 keine Joins. Dennoch
war performante Programmierung möglich.
2. JOINS über mehrere Tabellen sind meiner Meinung nach nicht immer leicht zu verstehen.
3. Es gibt wenige verlässliche Untersuchungen, welcher Zugriff am schnellsten ist. Ich habe vor Jahren in einem Buch, dessen Titel ich nicht mehr weiss (nicht SAP PRESS) über Perfomance-Analysen von SAP-Datenbankzugriffen gelesen, dass sich JOINS von DB zu DB unterschiedlich verhalten. ORACLE, Informix, MS-SQl. Bei ORACLE 8.x waren sie am besten. Auch die DB-Release spielt eine Rolle. Oftmals war ein ARRAY-Zugriff (select into table ) schneller. Selbst bei gleichem Betriebsystem. gleichem Datenbank-System und gleicher Hardware und ähnlicher Anzahl Einträge kann ich mir vorstellen, dass ein Zugriff unterschiedlich schnell ist, wenn auf unterschiedliche Weise rein geschrieben wurde.
Tach.
@meinrad:
Eine Diskussion pro/contra JOINs gab es hier schon mal, daher will ich mal nicht auf Übersichtlichkeit eingehen...
@Topic:
Ich bevorzuge JOINs. Aber: bei grossen Abfragen (über >3 Tabellen) kann es tatsächlich zu Performace-Engpässen kommen. Bei mir hat mal die Indexqualität eine Rolle gespielt. Durch viele DELETE's und INSERT's war der Primärindex so verclustert, dass der Optimizer immer zu einem Full Table Scan gegriffen hat. Nach einem Indexneuaufbau war alles tutti.
IMHO sollte man sich mit JOINs auskennen, wissen, wo es dabei haken kann und im Bedarfsfall andere Techniken anwenden können.
Gruss,
Haubi
@meinrad:
Eine Diskussion pro/contra JOINs gab es hier schon mal, daher will ich mal nicht auf Übersichtlichkeit eingehen...
@Topic:
Ich bevorzuge JOINs. Aber: bei grossen Abfragen (über >3 Tabellen) kann es tatsächlich zu Performace-Engpässen kommen. Bei mir hat mal die Indexqualität eine Rolle gespielt. Durch viele DELETE's und INSERT's war der Primärindex so verclustert, dass der Optimizer immer zu einem Full Table Scan gegriffen hat. Nach einem Indexneuaufbau war alles tutti.
IMHO sollte man sich mit JOINs auskennen, wissen, wo es dabei haken kann und im Bedarfsfall andere Techniken anwenden können.
Gruss,
Haubi
. Danke liebe Mitarbeiter 
. Gibt es da noch mehr?hallo,
kann dir noch den sql-trace empfehlen (ST05). ich bringe kein programm in das produktivsystem ohne eine laufzeitanalyse bzw. die zugriffe aus der st05 kontrolliert habe, wobei die se30 einfacher zu lesen ist, da du in der auswertung sofort sehen kannst auf welcher tabelle (zugriffe)
du die meiste zeit verlierst.
joachim
kann dir noch den sql-trace empfehlen (ST05). ich bringe kein programm in das produktivsystem ohne eine laufzeitanalyse bzw. die zugriffe aus der st05 kontrolliert habe, wobei die se30 einfacher zu lesen ist, da du in der auswertung sofort sehen kannst auf welcher tabelle (zugriffe)
du die meiste zeit verlierst.
joachim
Seite 1 von 1
Vergleichbare Themen
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 21 Stunden von ralf.wenzel 104 / 10274
vor 21 Stunden von ralf.wenzel 104 / 10274
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 21 Stunden von ralf.wenzel 104 / 10274
vor 21 Stunden von ralf.wenzel 104 / 10274