Inner Join Befehl

Inner Join Befehl

Hallo Leute,
ich habe ein Problem in ABAP, obwohl es eigentlich kein Problem sein sollte.

In der Selektion wird eine Materialnummer und eine Kundennummer vorgegeben.
Jetzt soll das definierte Feld "selknmt-kdmat" mit der Kd.Mat.Nummer gefüllt werden, wenn eine vorhanden ist, sonst soll das Feld leer bleiben.
Mach ich das am besten mit einem Join-Befehl?

Die Tabllenstruktur aus der die Kd.Mat.Nummer gelesen werden soll, sieht so aus: knmt~kunnr / knmt~matnr / knmt~kdmat
Die Felder aus der Selektion mit denen abgeglichen werden soll heißen: "selmara-matnr" & "dkunnr2"

Wie gehe ich da am besten vor? Für jemanden der sich auskennt sollte das ja eigentlich kein Problem sein, aber ich komm da nicht weiter

Danke schonmal für eure Hilfe
Gruß

Re: Inner Join Befehl

Hallo

Wenn dein Programm / Funktion sehr oft aufgerufen wird könnte der Funktionsbaustein "RV_CUSTOMER_MATERIAL_READ" besser geeignet sein, da dieser die knmt puffert und so nicht jedesmal auf die DB zugreiffen muss wenn ein schonmal gelesener Satz erneut angefragt wird. Die KNMT hat ebenfalls vkorg und vtweg als Key-Felder diese solltest du ebenfalls mit abfragen (auch wenn es in eurem System derzeit nur eine vkorg/vtweg gibt) um nicht am Index vorbei zu fragen.

Grüsse

Re: Inner Join Befehl

Key-Felder abfragen würde ich mir sofort angewöhnen, Ausbildung oder nicht. Das machen selbst die meisten gestandenen Berater noch falsch und interessieren sich nur für die von ihnen konkret benötigten Felder und wundern sich, wenn die Systemperformance leidet (oder fragen gar nicht danach).

Das disziplinierte Selektieren der Schlüsselfelder verleiht Dir auf die Dauer auch ein Gefühl dafür, wie ein guter Tabellenschlüssel aussehen sollte. Das ist wichtig, wenn Du selber mal Tabellen anlegst (und das wirst Du früher oder später). Auch hier gilt, dass die meisten Berater nach dem Prinzip vorgehen "Hauptsache so viele Felder als Schlüsselfelder definieren, dass man nie in eine Fehlermeldung wegen eines doppelten Schlüssels reinläuft und insofern seine Ruhe hat. Reihenfolge ist egal, und im Zweifel macht man halt alle Tabellenfelder zum Schlüssel, dann kann nichts anbrennen." Sowas ist natürlich eine Designkatastrophe, die sich früher oder später rächt. Nicht nur wird der Speicherplatzbedarf dadurch höher und die Performance schlechter, sondern die Wahrscheinlichkeit, Programmierfehler zu machen, steigt auch, denn ein guter Tabellenschlüssel ist ein orientierendes Gerüst, das einen zwingt, darüber nachzudenken, was man macht und häufig auch in die richtige Richtung leitet. Der Code wird dadurch auch klarer und besser verständlich. So kann eine einzige mies definierte Tabelle im weiteren Verlauf viele darauf aufbauende Programme unübersichtlich und fehleranfällig machen. Später kriegt man das kaum noch geradegebogen.

Darum: In den Primärschlüssel so wenig Felder wie möglich, so viele wie nötig, und die Reihenfolge stets so wählen, dass die in einem SELECT am wahrscheinlichsten bekannten Felder zuerst kommen, danach die Felder, die man oft nur auf größer/kleiner prüft (z.B. ein Beginn- und Endedatum) und danach erst das übrige Geraffel, über das man selten bis nie (oder nur mittels eines sekundären Index) sucht. (Das mit dem größer/kleiner deshalb, weil die Datenbank den Schlüssel nur bis zum ersten Feld für die Performance nutzen kann, das auf größer/kleiner geprüft wird, einschließlich dieses Feldes selbst, aber keine Felder danach mehr. Daher sollten möglichst alle (auf Gleichheit) bekannten Schlüsselfelder davor im Index liegen.)

Was Deine konkrete Frage angeht, so würde ich persönlich keinen IF-Block hinter dem SELECT machen, sondern einen CLEAR-Befehl vor den SELECT stellen. Liest sich wesentlich besser, und der Unterschied ist von der Performance her vernachlässigbar.

Wäre es ein SELECT über mehrere Tabellen, dan wäre Dein Problem übrigens ein typisches Indiz dafür, keinen INNER, sondern einen LEFT OUTER Join zu verwenden.