Inner Join bessere Performance

Inner Join bessere Performance

Hallo,

ich habe einen Inner Join, der leider sehr langsam ist. Ich möchte nun zusätzlich noch auf ein Feld prüfen, ob die ersten 5 Stellen gleich "G03786" beinhaltet also in der where-bedingung.

also Select .........
from ..... inner join.......
into table......
where
dph~mastr = 'G03786'.

Das Feld mastr hat nicht nur 5 Stellen sondern 12. Mich interessiert aber nur ob die ersten 5 Stellen diese Bedinung erfüllen. Wie könnte ich da vorgehen?? einfach die ersten fünf Stellen funktionert nicht.

Vielen Dank

Re: Inner Join bessere Performance

Hallo L0w-RiDer,

man sollte grundsätzlich immer so viel vom Schlüssel mitnehmen wie möglich.

Hast du schon einmal einen View mit den beiden Tabellen erstellt? Das kannst du in der SE11 anlegen und sollte eine bessere Performance liefern.

Zudem um deinen Wert mit in die Where-Bedingung zu nehmen solltest du mit LIKE arbeiten und % (beliebige Zeichenkette):

where
dph~mastr LIKE 'G03786%'.


Lieben Gruß
Veit

Re: Inner Join bessere Performance

hmm irgendwie bekomme ich mit diesem like-befehl auch immer nur 0 Einträge. Das Feld soll nicht gleich diesen 5 Stellen sein, dass Feld ist 12 Stellen lang. Ich möchte nur prüfen ob die ersten 5 Stellen diese Kombination aufweist.

Re: Inner Join bessere Performance

Das mit dem "soviel vom Primärschlüssel wie möglich angeben" haut so auch nicht hin bzw. ist zu ungenau formuliert. Hinsichtlich der Performance bringt es nur was, wenn man so viele Felder wie möglich angibt, die der Reihenfolge des Primärschlüssels entsprechen. Zudem müssen diese auf Gleichheit (oder IN-Operator) geprüft werden. Fehlt ein Feld des Primärschlüssels, dann bringen nachfolgende Schlüsselfelder auch nichts mehr.

Wenn die Tabelle also z.B. einen Primärschlüssel mit den Schlüsselfeldern A, B, C, D und E hat und man

WHERE A = 1 AND B = 2 AND D = 3

schreibt, dann nützt die Einschränkung von D hinsichtlich der Performance gar nichts, da C fehlt. Auch wenn man

WHERE A = 1 AND B = 2 AND C > 3 AND D = 5

schreibt, nützt die Angabe von D der Performance nichts, da man C nicht auf Gleichheit geprüft hat. Beim letzten Feld ab Schlüsselbeginn bringt allerdings auch eine Prüfung auf Ungleichheit was, also ist die Angabe C > 3 in diesem Beispiel noch performancetechnisch hilfreich.

Diese Zusammenhänge sollte man schon im Auge haben, wenn man den Primärschlüssel einer Tabelle definiert. Die Reihenfolge ist eben nicht egal! Sie sollte so gewählt werden, dass die Schlüsselfelder absteigend nach der Wahrscheinlichkeit sortiert sind, bei einem Zugriff bekannt zu sein.

Ein gutes Beispiel ist z.B. die Tabelle PA0001 mit dem Schlüssel

PERNR
SUBTY
OBJPS
SPRPS
ENDDA
BEGDA

ENDDA ist "Endedatum", und BEGDA ist "Beginndatum". Warum also hat die SAP ENDDA zuerst aufgeführt? Weil man bei der Suche nach Datensätzen meist nur den aktuellen Wert oder solche haben möchte, die in der Zukunft erst beginnen. Die ganzen alten, nicht mehr gültigen Sätze früherer Jahre will man nicht mehr haben.

Daher wird man meist mit einer Einschränkung wie ENDDA >= STICHTAG suchen. Da ENDDA zuerst kommt, hat die Datenbank die Chance, trotz der Prüfung auf Ungleichheit die ganzen alten Sätze direkt zu überspringen und performant nach dem ENDDA zu suchen. Das BEGDA ist hingegen weniger relevant. Bei der Suche nach Sätzen, die an einem Stichtag gelten, wird man zwar auch BEGDA <= STICHTAG fordern. Es macht aber in aller Regel weniger aus, wenn das nicht in die Performance eingeht, denn es kann viele veraltete Sätze geben, die keine Bedeutung mehr haben, aber Sätze, die in der Zukunft erst beginnen, hat man in aller Regel nur einen oder zwei, wenn überhaupt. Die kann man also unproblematisch sequentiell ohne Optimierung durchsuchen. Von daher ist

ENDDA >= STICHTAG AND BEGDA <= STICHTAG

in der Praxis performanter als

BEGDA <= STICHTAG AND ENDDA >= STICHTAG

(bei jeweils entsprechender Reihenfolge der Felder in der Primärschlüsseldefinition der Tabelle).

Dass bei der SAP auch nur Menschen arbeiten, erkennt man daran, dass sie dies bei der Definition der Tabelle HRP1001 beachtet haben, bei der Definition der HRP1000 aber idiotischerweise nicht.